Bill, The PoP terminology in ancient IETF terminology coming from the IPsec WG (also home of IKE and IKEv2 protocols), and perhaps even before the IPsec WG. So its a well-known term in the Security Area. I'd suggest we keep it.
Folks that work in the Mail & routing area use the term POP3 or RFC1939 in their context. People in OASIS security-related Technical Committees use HOK (holder of key), such as the HOK Web Browser profile: https://wiki.oasis-open.org/security/SamlHoKWebSSOProfile /thomas/ ________________________________________ From: OAuth [oauth-boun...@ietf.org] on behalf of Bill Mills [wmi...@yahoo-inc.com] Sent: Thursday, April 03, 2014 12:06 PM To: Phil Hunt; Prateek Mishra; Hannes Tschofenig; Justin Richer; OAuth WG Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-pop-architecture-00.txt I really *like* the name "proof of possession", but I think the acronym PoP is going to be confused with POP. HOTK has the advantage of not being a homonym for aything else. What about "Possession Proof"? -bill -------------------------------- William J. Mills "Paranoid" MUX Yahoo! On Thursday, April 3, 2014 1:38 AM, "internet-dra...@ietf.org" <internet-dra...@ietf.org> wrote: A new version of I-D, draft-hunt-oauth-pop-architecture-00.txt has been successfully submitted by Hannes Tschofenig and posted to the IETF repository. Name: draft-hunt-oauth-pop-architecture Revision: 00 Title: OAuth 2.0 Proof-of-Possession (PoP) Security Architecture Document date: 2014-04-03 Group: Individual Submission Pages: 21 URL: http://www.ietf.org/internet-drafts/draft-hunt-oauth-pop-architecture-00.txt Status: https://datatracker.ietf.org/doc/draft-hunt-oauth-pop-architecture/ Htmlized: http://tools.ietf.org/html/draft-hunt-oauth-pop-architecture-00 Abstract: The OAuth 2.0 bearer token specification, as defined in RFC 6750, allows any party in possession of a bearer token (a "bearer") to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens must to be protected from disclosure in transit and at rest. Some scenarios demand additional security protection whereby a client needs to demonstrate possession of cryptographic keying material when accessing a protected resource. This document motivates the development of the OAuth 2.0 proof-of-possession security mechanism. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
