From nobody Tue Dec 1 10:08:31 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CF61B2E5C for ; Tue, 1 Dec 2015 10:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebCmYTaUZGkd for ; Tue, 1 Dec 2015 10:08:20 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26261B2E29 for ; Tue, 1 Dec 2015 10:08:20 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tB1I8EPK006147 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Dec 2015 18:08:14 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tB1I8D4f029950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Dec 2015 18:08:13 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tB1I8D1i030742; Tue, 1 Dec 2015 18:08:13 GMT Received: from [10.0.1.22] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Dec 2015 10:08:11 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_FB5590D0-C168-4E94-AF1D-2E2D5C8A41EE" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Phil Hunt In-Reply-To: Date: Tue, 1 Dec 2015 10:08:10 -0800 Message-Id: References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> <1AD1F44B-9837-4288-9997-5292F1DBE30E@oracle.com> <9E20E73C-AC35-4E03-A011-119A32CD0BF1@ve7jtb.com> <7431079B-818C-46E9-8102-D193E49384B2@gmail.com> <638FA321-4DE1-467C-9B5C-3BEA0EC3EB0F@mit.edu> <207E620F-97AA-4851-8776-2A7B1921D58A@ve7jtb.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3096.5) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 18:08:29 -0000 --Apple-Mail=_FB5590D0-C168-4E94-AF1D-2E2D5C8A41EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99ve reviewed the comments from John, Justin and Kathleen. As = suggested, I plan to remove the erroneous first paragraph in section 5 = (draft 06). Combining the comments from this thread about sec 6, here is the = proposed new first paragraph: A large range of threats can be mitigated by protecting the content of the token, for example using a digital signature or a keyed message digest. Alternatively, the content of the token could be passed by reference rather than by value (requiring a separate message exchange to resolve the reference to the token content). To simplify the subsequent description we assume in the PoP architecture that the token itself is integrity protected by the authorization server and the token remains opaque to the client. The token itself cannot be modified by the client, either due to cryptographic protection (such as signature or encryption) or use of a reference value with sufficient entropy and associated secure lookup. These are characteristics shared with bearer tokens and more information on best practices can be found in [RFC6819] and in the security considerations section of [RFC6750]. If this looks good to the group, I=E2=80=99ll post draft 7 this = afternoon (pacific). Thanks, Phil @independentid www.independentid.com phil.hunt@oracle.com > On Nov 25, 2015, at 2:19 PM, Kathleen Moriarty = wrote: >=20 >=20 >=20 > On Wed, Nov 25, 2015 at 3:58 PM, John Bradley > wrote: > I am fine with that, however saying integrity protected, may be better = than signed. May people will argue that HMAC or encryption with sender = verification is not signature. >=20 > Good point, I also prefer integrity protected. Are we all good with = this now? I'd like to look at a diff to make sure after following the = thread. >=20 > Thanks! > Kathleen >=20 > =20 > However they are perfectly valid. >=20 >=20 >> On Nov 25, 2015, at 5:53 PM, Justin Richer > wrote: >>=20 >> The requirement is not that signed JWTs be used, it=E2=80=99s that = unsigned JWTs not be used on their own. Reference tokens and encrypted = JWTs are also valid, as are other signed formats like SAML assertions or = even a COSE Token (if it=E2=80=99s encoded to HTTP friendliness).=20 >>=20 >> My recommendation: >>=20 >> Remove the erroneous requirement text from section 5 and restore to = previous version. >>=20 >> Amend the text in section 6 from: >>=20 >> To >> simplify the subsequent description we assume in the PoP = architecture >> that the token itself is digitally signed by the authorization = server >> and therefore cannot be modified. >>=20 >>=20 >> To: >>=20 >> In all such cases, the token remains opaque to the client. To >> simplify the subsequent example and description we assume in the = PoP architecture >> that the token itself cannot be modified by the client, either due = to >> cryptographic protection (such as signature or encryption) or use = of=20 >> a reference value with sufficient entropy and associated secure = lookup. >> These are characteristics shared with bearer tokens and more = information >> on best practices can be found in [[RFC6819]] and in the security=20= >> considerations section of [[RFC6750]].=20 >>=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Nov 25, 2015, at 3:39 PM, Kathleen Moriarty = > wrote: >>>=20 >>> Hi, >>>=20 >>> Sent from my iPhone >>>=20 >>> On Nov 25, 2015, at 3:20 PM, John Bradley > wrote: >>>=20 >>>> Tokens are signed or the information is otherwise integrity = protected between the AS and the RS. =20 >>>>=20 >>>> I suspect Kathleen is concerned about the key getting modified in = transit. =20 >>>> That needs to be protected against, but there is more than one way = to do that. >>>=20 >>> Phil is correct. I was looking for consistency between the sections = since they related to each other. If there is a security risk or = consideration, that needs to be explicitly called out as a concern such = as a key being modified in transit. If there are options to protect = against that, those would ideally be required or would have warnings. >>>>=20 >>>> So sending the public key in a unsigned JWT access token would be = immensely stupid, not just for PoP but for scopes and everything else. >>>=20 >>> Good, easy to require then. >>>=20 >>> Thanks, >>> Kathleen=20 >>>>=20 >>>> In OAuth 2 all tokens need to be integrity protected between the AS = and RS. =20 >>>> That can be via signature, by having a reference with sufficient = entropy and secure introspection or database lookup. >>>>=20 >>>> I think that is a OAuth 2 security consideration. We are adding a = additional confirmation claim to the existing information that needs to = be protected the same as the rest. >>>>=20 >>>> John B. >>>>=20 >>>>=20 >>>>> On Nov 25, 2015, at 4:38 PM, Phil Hunt > wrote: >>>>>=20 >>>>> >>>>> If there is agreement that tokens are opaque then the requirement = that tokens be signed must be removed from the threat mitigation = requirements.=20 >>>>>=20 >>>>> And the paragraph in sec 5 that brian was concerned about be = restored.=20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>> On Nov 25, 2015, at 11:24, Justin Richer > wrote: >>>>>=20 >>>>>> It is still end to end authentication with opaque tokens =E2=80=94 = since all OAuth tokens, including PoP tokens, have always been intended = to be opaque to the client. That hasn=E2=80=99t changed and that isn=E2=80= =99t the intent of this document. If that=E2=80=99s how people are = reading it then we need to pull it back and rewrite it so that=E2=80=99s = not the case. >>>>>>=20 >>>>>> The client gets a token that has two parts: the token and the = key. The token is analogous to the access_token we have today and would = come out of the server in the same field. The key is handed to the = client alongside the token or registered by the client during the token = request. Either way there=E2=80=99s an association between the two but = it=E2=80=99s not the same association as a public/private keypair.=20 >>>>>>=20 >>>>>> It=E2=80=99s possible to sign the token itself, but the client = doesn=E2=80=99t care. It sends the token and signs the HTTP request to = the RS whether the token is signed, unsigned, hex blob, encrypted, or = anything else. The same series of options are available as with bearer = tokens. PoP tokens have never, ever been intended to be anything but = opaque to the client. >>>>>>=20 >>>>>> The token can=E2=80=99t be opaque to the RS, which has to figure = out what key to use to check the message signature. But we=E2=80=99ve = got options there, like the embedded key in a JWT from Mike=E2=80=99s = draft, or doing introspection to get the key (from an extension that = hasn=E2=80=99t been written yet), or simply looking it up in the same = database because the RS and the AS are in the same box. Does this = structure/service/database choice sound familiar? It should, it=E2=80=99s = the same as bearer tokens. This is also how the RS gets information like = which scopes are associated with the token, if it=E2=80=99s expired, and = all that.=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> So here=E2=80=99s how I see it going on the wire: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> (I just wrote this up so there are probably holes. Here=E2=80=99s = the source if anyone wants to tweak it: = http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW50IGFzIEMKA= AwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3R= lY3RlZABICmFzIFJTCgoKClJPLS0 = -QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmV= jdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAK= QcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADA= FKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIA= E8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmN= sdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduY= XR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwB= iBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZ= CkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4= OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&= s=3Dmodern-blue ) >>>>>>=20 >>>>>> The client is oblivious to the token just like always. This is = intentional. The RS has the same options to figure out how to process = the token. >>>>>>=20 >>>>>> =E2=80=94 Justin >>>>>>=20 >>>>>>> On Nov 25, 2015, at 2:03 PM, Phil Hunt > wrote: >>>>>>>=20 >>>>>>> Folks,=20 >>>>>>>=20 >>>>>>> >>>>>>> I did not want to go here either. :-) >>>>>>>=20 >>>>>>> I don=E2=80=99t read sec 6 as examples. I believe this may stem = from the pop-architecture documents having a dual role as both = =E2=80=9Carchitecture=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D. Maybe we = should clarify the purpose of the document? >>>>>>>=20 >>>>>>> I believe section 6 is talking about threat mitigation = assumptions based on the examples that need to be implemented. I am = assuming these are requirements that the other specifications SHOULD = implement. >>>>>>>=20 >>>>>>> >>>>>>> I do not believe we have discussed Opaque PoP tokens and any = inherent risks because the client is not or is unable to validate the = authenticity of the token. Does this introduce the possibility of a = MITM attack where a client can be convinced to sign requests for an = attacker? >>>>>>>=20 >>>>>>> If we want to include opaque PoP, I think we need to take a = pause and consider / discuss any threats here. >>>>>>>=20 >>>>>>> I find the desire for opaque PoP tokens to be a bit = contradictory. If we=E2=80=99re saying we don=E2=80=99t want to trust = TLS alone (e.g. because of load-balancer termination), why would we then = say, but we are perfectly willing to accept it worked for the OAuth AS = exchanges? Maybe I was very wrong here, but my assumption all along is = that for PoP we=E2=80=99re talking about end-to-end authentication of = all parties except in the case of 3.3 where we simply want to protect an = access token over a non-TLS HTTP connection. >>>>>>>=20 >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>> @independentid >>>>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>>>> On Nov 25, 2015, at 10:48 AM, Brian Campbell = > wrote: >>>>>>>>=20 >>>>>>>> While I can't say I disagree with the deeper existential = questions about the draft that Justin raises, I was trying not to go = there and rather just point out concerns with the newly added text.=20 >>>>>>>>=20 >>>>>>>> The text Phil cites from Sec 6 doesn't say the client must be = able to parse and verify the token. It's an assumption to simplify the = examples that follow and still the token is opaque to the client. I = reread the whole draft (reluctantly) and there's nothing that says the = token has to be non-opaque to the client. And it does talk about = reference style tokens and encrypted tokens, both of which rely on the = opaqueness to the client.=20 >>>>>>>>=20 >>>>>>>> On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer = > wrote: >>>>>>>> Right, I read that as text for describing the examples and not = for describing requirements. >>>>>>>>=20 >>>>>>>> The token itself doesn=E2=80=99t have to be signed at all. >>>>>>>>=20 >>>>>>>> =E2=80=94 Justin >>>>>>>>=20 >>>>>>>>> On Nov 25, 2015, at 1:05 PM, Phil Hunt > wrote: >>>>>>>>>=20 >>>>>>>>> Ok. Well this was requested by Kathleen because of this = paragraph in Sec 6.=E2=80=A6 >>>>>>>>>=20 >>>>>>>>> To simplify the subsequent description we assume in the PoP = architecture >>>>>>>>> that the token itself is digitally signed by the = authorization server >>>>>>>>> and therefore cannot be modified. >>>>>>>>>=20 >>>>>>>>> Please=20 >>>>>>>>> Phil >>>>>>>>>=20 >>>>>>>>> @independentid >>>>>>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>>>>>> On Nov 25, 2015, at 9:33 AM, Justin Richer > wrote: >>>>>>>>>>=20 >>>>>>>>>> The token doesn=E2=80=99t have to be signed and the client = doesn=E2=80=99t have to verify the signature on the token. That=E2=80=99s = not PoP. The request has to be signed in a way that includes the token. = The token itself can still be opaque. The *key* material can=E2=80=99t = be opaque to the client, but the *token* material still is. >>>>>>>>>>=20 >>>>>>>>>> I agree with Brian that this statement is misleading. >>>>>>>>>>=20 >>>>>>>>>> The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one style. >>>>>>>>>>=20 >>>>>>>>>> What=E2=80=99s most difficult about this particular spec is = that it=E2=80=99s very hand-wavy, saying =E2=80=9Cthis is kinda a thing = that kinda works like this=E2=80=9D without saying how to actually do = it. I=E2=80=99m honestly not sure it=E2=80=99s worth publishing as an = RFC in its own right but I=E2=80=99m not going to stand in its way. >>>>>>>>>>=20 >>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>=20 >>>>>>>>>>> On Nov 25, 2015, at 12:14 PM, Brian Campbell = > wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Where does it say that?=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt = > wrote: >>>>>>>>>>> Except that later on we require the token be signed and the = client verify that signed token. IOW mutual pop.=20 >>>>>>>>>>>=20 >>>>>>>>>>> Phil >>>>>>>>>>>=20 >>>>>>>>>>> On Nov 25, 2015, at 07:30, Brian Campbell = > wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Looking at the diff I noticed the following new text, which = seems to conflate bearer/PoP and opaqueness to the client. A client = demonstrating proof-of-possession of some key is orthogonal to the = client being able to parse and understand the access token itself.=20 >>>>>>>>>>>> =20 >>>>>>>>>>>> "In contrast to bearer tokens [RFC6750] which call for = tokens that are opaque to OAuth 2.0 clients, this specification defines = the requirements for proof-of-possession ("PoP") tokens that may be = parsed and verified by OAuth 2.0 clients and relying parties." >>>>>>>>>>>>=20 >>>>>>>>>>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt = > wrote: >>>>>>>>>>>> This draft addresses review comments from Kathleen and Erik = raised since the last draft. >>>>>>>>>>>>=20 >>>>>>>>>>>> It may not include some of the discussion from = yesterday/today. I will add that as the group decides. >>>>>>>>>>>>=20 >>>>>>>>>>>> Cheers, >>>>>>>>>>>>=20 >>>>>>>>>>>> Phil >>>>>>>>>>>>=20 >>>>>>>>>>>> @independentid >>>>>>>>>>>> www.independentid.com >>>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>>=20 >>>>>>>>>>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org = wrote: >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>>>>>>> > This draft is a work item of the Web Authorization = Protocol Working Group of the IETF. >>>>>>>>>>>> > >>>>>>>>>>>> > Title : OAuth 2.0 Proof-of-Possession = (PoP) Security Architecture >>>>>>>>>>>> > Authors : Phil Hunt >>>>>>>>>>>> > Justin Richer >>>>>>>>>>>> > William Mills >>>>>>>>>>>> > Prateek Mishra >>>>>>>>>>>> > Hannes Tschofenig >>>>>>>>>>>> > Filename : = draft-ietf-oauth-pop-architecture-06.txt >>>>>>>>>>>> > Pages : 23 >>>>>>>>>>>> > Date : 2015-11-24 >>>>>>>>>>>> > >>>>>>>>>>>> > 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 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. >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > The IETF datatracker status page for this draft is: >>>>>>>>>>>> > = https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ = >>>>>>>>>>>> > >>>>>>>>>>>> > There's also a htmlized version available at: >>>>>>>>>>>> > = https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 = >>>>>>>>>>>> > >>>>>>>>>>>> > A diff from the previous version is available at: >>>>>>>>>>>> > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 = = >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > 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 . >>>>>>>>>>>> > >>>>>>>>>>>> > Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>>> > ftp://ftp.ietf.org/internet-drafts/ = >>>>>>>>>>>> > >>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>> > OAuth mailing list >>>>>>>>>>>> > OAuth@ietf.org >>>>>>>>>>>> > https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> --=20 >>>>>>>>>>>> =09 >>>>>>>>>>>> Brian Campbell >>>>>>>>>>>> Distinguished Engineer >>>>>>>>>>>> Ping Identity >>>>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>>> @pingidentity >>>>>>>>>>>> Connect with us! >>>>>>>>>>>> = >>>>>>>>>>>> = = = = = = = = >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> --=20 >>>>>>>>>>> =09 >>>>>>>>>>> Brian Campbell >>>>>>>>>>> Distinguished Engineer >>>>>>>>>>> Ping Identity >>>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>> @pingidentity >>>>>>>>>>> Connect with us! >>>>>>>>>>> = >>>>>>>>>>> = = = = = = = = _____________________________________= __________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>> =09 >>>>>>>> Brian Campbell >>>>>>>> Distinguished Engineer >>>>>>>> Ping Identity >>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>> +1 720.317.2061 >>>>>>>> @pingidentity >>>>>>>> Connect with us! >>>>>>>> = >>>>>>>> = = = = = = = = >>>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_FB5590D0-C168-4E94-AF1D-2E2D5C8A41EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99ve reviewed the comments from John, Justin and = Kathleen. As suggested, I plan to remove the erroneous first paragraph = in section 5 (draft 06).

Combining the comments from this thread about sec 6, here is = the proposed new first paragraph:

 A large range of threats can be =
mitigated by protecting the content
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).  To
   simplify the subsequent description we assume in the PoP architecture
   that the token itself is integrity protected by the authorization
   server and the token remains opaque to the client.  The token itself
   cannot be modified by the client, either due to cryptographic
   protection (such as signature or encryption) or use of a reference
   value with sufficient entropy and associated secure lookup.  These
   are characteristics shared with bearer tokens and more information on
   best practices can be found in [RFC6819] and in the security
   considerations section of [RFC6750].
If this = looks good to the group, I=E2=80=99ll post draft 7 this afternoon = (pacific).

Thanks,


On Nov 25, 2015, at 2:19 PM, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> wrote:



On Wed, Nov 25, 2015 at 3:58 PM, John Bradley = <ve7jtb@ve7jtb.com> wrote:
I am fine with that, however = saying integrity protected, may be better than signed.  May people = will argue that HMAC or encryption with sender verification is not = signature.

Good point, I also prefer integrity protected.  Are we = all good with this now?  I'd like to look at a diff to make sure = after following the thread.

Thanks!
Kathleen
 
However they are perfectly valid.


On Nov 25, 2015, at 5:53 PM, Justin Richer = <jricher@mit.edu> wrote:

The = requirement is not that signed JWTs be used, it=E2=80=99s that unsigned = JWTs not be used on their own. Reference tokens and encrypted JWTs are = also valid, as are other signed formats like SAML assertions or even a = COSE Token (if it=E2=80=99s encoded to HTTP friendliness). 

My = recommendation:

Remove the erroneous requirement text from section 5 and = restore to previous version.

Amend the text in section 6 = from:

   To
   simplify the subsequent description we assume in the PoP architecture

   that the token itself is digitally signed by =
the authorization server
   and therefore cannot be modified.


To:

   In all such cases, the token remains =
opaque to the client. To
   simplify the subsequent example and description we assume in the PoP =
architecture
   that the token itself cannot be =
modified by the client, either due to
   =
cryptographic protection (such as signature or encryption) or use =
of 
   a reference value with sufficient =
entropy and associated secure lookup.
   These are =
characteristics shared with bearer tokens and more information
   on best practices can be found in [[RFC6819]] and in the =
security 
   considerations section of =
[[RFC6750]].


 =E2=80=94 = Justin

On Nov 25, 2015, at 3:39 PM, = Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> = wrote:

Hi,

Sent from my iPhone

On = Nov 25, 2015, at 3:20 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Tokens are signed or the information is otherwise integrity = protected between the AS and the RS.  

I suspect Kathleen is concerned about = the key getting modified in transit.   
That needs to be protected against, but there is more than = one way to do that.

Phil is correct.  I was looking for consistency = between the sections since they related to each other.  If there is = a security risk or consideration, that needs to be explicitly called out = as a concern such as a key being modified in transit.  If there are = options to protect against that, those would ideally be required or = would have warnings.

So sending the public key in a unsigned JWT access token = would be immensely stupid,  not just for PoP but for scopes and = everything else.

Good, easy to require then.

Thanks,
Kathleen 

In OAuth 2 all tokens need to be integrity protected between = the AS and RS.  
That can be via signature, =  by having a reference with sufficient entropy and secure = introspection or database lookup.

I think that is a OAuth 2 security = consideration.   We are adding a additional confirmation claim to = the existing information that needs to be protected the same as the = rest.

John = B.


On Nov 25, 2015, at 4:38 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

<editors = hat>
If there is agreement that tokens are = opaque then the requirement that tokens be signed must be removed from = the threat mitigation requirements. 

And the paragraph in sec 5 that brian = was concerned about be restored. 

Phil

On Nov 25, 2015, at 11:24, Justin Richer <jricher@mit.edu> wrote:

It = is still end to end authentication with opaque tokens =E2=80=94 since = all OAuth tokens, including PoP tokens, have always been intended to be = opaque to the client. That hasn=E2=80=99t changed and that isn=E2=80=99t = the intent of this document. If that=E2=80=99s how people are reading it = then we need to pull it back and rewrite it so that=E2=80=99s not the = case.

The client = gets a token that has two parts: the token and the key. The token is = analogous to the access_token we have today and would come out of the = server in the same field. The key is handed to the client alongside the = token or registered by the client during the token request. Either way = there=E2=80=99s an association between the two but it=E2=80=99s not the = same association as a public/private keypair. 

It=E2=80=99s possible to = sign the token itself, but the client doesn=E2=80=99t care. It sends the = token and signs the HTTP request to the RS whether the token is signed, = unsigned, hex blob, encrypted, or anything else. The same series of = options are available as with bearer tokens. PoP tokens have never, ever = been intended to be anything but opaque to the client.

The token can=E2=80=99t = be opaque to the RS, which has to figure out what key to use to check = the message signature. But we=E2=80=99ve got options there, like the = embedded key in a JWT from Mike=E2=80=99s draft, or doing introspection = to get the key (from an extension that hasn=E2=80=99t been written yet), = or simply looking it up in the same database because the RS and the AS = are in the same box. Does this structure/service/database choice sound = familiar? It should, it=E2=80=99s the same as bearer tokens. This is = also how the RS gets information like which scopes are associated with = the token, if it=E2=80=99s expired, and all that. 




So here=E2=80=99s how I see it going on the wire:



3D"http://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DcGFydGljaXBhb=



(I just wrote this up so = there are probably holes. Here=E2=80=99s the source if anyone wants to = tweak it: http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW= 50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZB= UwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPl= JPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAV= BwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcm= VxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsA= EAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUz= ogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVj= awCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludH= Jvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGlj= IG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAI= QoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiBy= ZXR1cm4AhicJ&s=3Dmodern-blue )

The client is oblivious to the token = just like always. This is intentional. The RS has the same options to = figure out how to process the token.

 =E2=80=94 Justin

On Nov 25, 2015, at 2:03 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Folks, 

<editor = hat>
I did not want to go here either. = :-)

I don=E2=80=99= t read sec 6 as examples.  I believe this may stem from the = pop-architecture documents having a dual role as both =E2=80=9Carchitectur= e=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D.  Maybe we should clarify = the purpose of the document?

I believe section 6 is talking about = threat mitigation assumptions based on the examples that need to be = implemented.  I am assuming these are requirements that the other = specifications SHOULD implement.

<personal hat>
I do not believe we have discussed Opaque PoP tokens and any = inherent risks because the client is not or is unable to validate the = authenticity of the token.  Does this introduce the possibility of = a MITM attack where a client can be convinced to sign requests for an = attacker?

If = we want to include opaque PoP, I think we need to take a pause and = consider / discuss any threats here.

I find the desire for opaque PoP tokens = to be a bit contradictory. If we=E2=80=99re saying we don=E2=80=99t want = to trust TLS alone (e.g. because of load-balancer termination), why = would we then say, but we are perfectly willing to accept it worked for = the OAuth AS exchanges?  Maybe I was very wrong here, but my = assumption all along is that for PoP we=E2=80=99re talking about = end-to-end authentication of all parties except in the case of 3.3 where = we simply want to protect an access token over a non-TLS HTTP = connection.



On Nov 25, 2015, at 10:48 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

While I can't say I disagree with the deeper = existential questions about the draft that Justin raises, I was trying = not to go there and rather just point out concerns with the newly added = text.

The text Phil cites from Sec 6 = doesn't say the client must be able to parse and verify the token. It's = an assumption to simplify the examples that follow and still the token = is opaque to the client. I reread the whole draft (reluctantly) and = there's nothing that says the token has to be non-opaque to the client. = And it does talk about reference style tokens and encrypted tokens, both = of which rely on the opaqueness to the client.

On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer = <jricher@mit.edu> wrote:
Right, I read that as text for = describing the examples and not for describing requirements.

The token itself = doesn=E2=80=99t have to be signed at all.

 =E2=80=94 Justin

On Nov 25, 2015, at 1:05 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:

Ok. Well this was = requested by Kathleen because of this paragraph in Sec 6.=E2=80=A6

   =
To simplify the subsequent description we assume in the PoP =
architecture
   =
that the token itself is digitally signed by the authorization server

   and therefore cannot be modified.

Please 

On Nov 25, 2015, at 9:33 AM, Justin Richer <jricher@mit.edu> wrote:

The token = doesn=E2=80=99t have to be signed and the client doesn=E2=80=99t have to = verify the signature on the token. That=E2=80=99s not PoP. The request = has to be signed in a way that includes the token. The token itself can = still be opaque. The *key* material can=E2=80=99t be opaque to the = client, but the *token* material still is.

I agree with Brian that this statement = is misleading.

The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one = style.

What=E2=80= =99s most difficult about this particular spec is that it=E2=80=99s very = hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda works like = this=E2=80=9D without saying how to actually do it. I=E2=80=99m honestly = not sure it=E2=80=99s worth publishing as an RFC in its own right but = I=E2=80=99m not going to stand in its way.

 =E2=80=94 Justin

On Nov 25, 2015, at 12:14 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

Where does it say = that?



On Wed, = Nov 25, 2015 at 8:44 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Except that later on we require the token be = signed and the client verify that signed token. IOW mutual = pop. 

Phil

On Nov 25, 2015, at 07:30, = Brian Campbell <bcampbell@pingidentity.com> = wrote:

Looking at the = diff I noticed the following new text, which seems to conflate = bearer/PoP and opaqueness to the client. A client demonstrating = proof-of-possession of some key is orthogonal to the client being able = to parse and understand the access token itself.
 
"In contrast to bearer tokens [RFC6750] which call for tokens = that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
This draft = addresses review comments from Kathleen and Erik raised since the last = draft.

It may not include some of the discussion from yesterday/today.  I = will add that as the group decides.

Cheers,

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF.
>
>        Title          =  : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors        =  : Phil Hunt
>                  =         Justin Richer
>                  =         William Mills
>                  =         Prateek Mishra
>                  =         Hannes Tschofenig
>       Filename        : = draft-ietf-oauth-pop-architecture-06.txt
>       Pages          =  : 23
>       Date          =   : 2015-11-24
>
> 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 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.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth






--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


________________________________= _______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
________________________________= _______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





--

Best regards,
Kathleen
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_FB5590D0-C168-4E94-AF1D-2E2D5C8A41EE-- From nobody Tue Dec 1 10:27:31 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706261B2EC1 for ; Tue, 1 Dec 2015 10:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKuQDMBF0w6N for ; Tue, 1 Dec 2015 10:27:22 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 437851B2EB5 for ; Tue, 1 Dec 2015 10:27:21 -0800 (PST) X-AuditID: 12074423-f797f6d0000023d0-ba-565de68651e1 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id AA.0D.09168.686ED565; Tue, 1 Dec 2015 13:27:18 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id tB1IRH4d001027; Tue, 1 Dec 2015 13:27:17 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tB1IRFMP013246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Dec 2015 13:27:16 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_5809D437-FEBA-47E9-A7C1-9F9688B5A550" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: Date: Tue, 1 Dec 2015 13:27:15 -0500 Message-Id: <8F038A71-C047-42F6-9BA9-D697A14902E1@mit.edu> References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> <1AD1F44B-9837-4288-9997-5292F1DBE30E@oracle.com> <9E20E73C-AC35-4E03-A011-119A32CD0BF1@ve7jtb.com> <7431079B-818C-46E9-8102-D193E49384B2@gmail.com> <638FA321-4DE1-467C-9B5C-3BEA0EC3EB0F@mit.edu> <207E620F-97AA-4851-8776-2A7B1921D58A@ve7jtb.com> To: Phil Hunt X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsUixG6notv2LDbM4OQtGYuGnfkWJ9++YrNY ML+R3YHZY+esu+weS5b8ZPL4+PQWSwBzFJdNSmpOZllqkb5dAlfGj0eXGAvePmSteN/+h7mB cXM7axcjJ4eEgInEhPZ2JghbTOLCvfVsXYxcHEICi5kkVl08ygzhbGCUOHJzLiuE84BJ4sCf X+wgLcwCCRKrGt+ygdi8AnoSr25dBhsrLOAjcfH0EzCbTUBVYvqaFrAVnAJ2Ek1HDoPVswio SGx4+AhqTprE7ukg20DmWEk07D3IArHsErvEnw0HwRIiQA3frl5nhLhVVmL370dMExgFZiG5 YxaSOyDi2hLLFr5mhrA1JfZ3L2fBFNeQ6Pw2kXUBI9sqRtmU3Crd3MTMnOLUZN3i5MS8vNQi XTO93MwSvdSU0k2M4FhwUd7B+Oeg0iFGAQ5GJR5eibUxYUKsiWXFlbmHGCU5mJREeQMfxIYJ 8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuF9uhYox5uSWFmVWpQPk5LmYFES5537xTdMSCA9sSQ1 OzW1ILUIJivDwaEkwTsFZKhgUWp6akVaZk4JQpqJgxNkOA/Q8JUgNbzFBYm5xZnpEPlTjIpS 4rxdIAkBkERGaR5cLyhVJbw9bPqKURzoFWHeMyBVPMA0B9f9CmgwE9DgD3+iQQaXJCKkpBoY 904+d7qwxGFm0fpGtTY9y29z+K86X/zVfmrivQeZvS3rmY40PFvGEbSe3d7r9llVzrf9LVd8 7p7bqS6yl+FGT35QbHFbhetigx3t/Ke3rmPbMa3s+JV8EfvuOcrc2/e8rLS2tZ29LGHGnhvM JxZX5E0zDL2x9mCEYFKAoYErU6FEhttSXbdqJZbijERDLeai4kQAnO05BjADAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 18:27:30 -0000 --Apple-Mail=_5809D437-FEBA-47E9-A7C1-9F9688B5A550 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That=E2=80=99s much better. I would also suggest that a few edits to = hammer home that this is an example > A large range of threats can be mitigated by protecting the content > of the token, for example using a digital signature or a keyed > message digest. Alternatively, the content of the token could be > passed by reference rather than by value (requiring a separate > message exchange to resolve the reference to the token content). = To > simplify discussion in the following example we assume=20 > that the token itself [=E2=80=A6] > cannot be modified by the client, either due to cryptographic > protection (such as signature or encryption) or use of a reference > value with sufficient entropy and associated secure lookup. The = token remains opaque to the client. > These > are characteristics shared with bearer tokens and more information = on > best practices can be found in [RFC6819] and in the security > considerations section of [RFC6750]. That=E2=80=99s really what=E2=80=99s going on by my read. Thoughts? =E2=80=94 Justin > On Dec 1, 2015, at 1:08 PM, Phil Hunt wrote: >=20 > I=E2=80=99ve reviewed the comments from John, Justin and Kathleen. As = suggested, I plan to remove the erroneous first paragraph in section 5 = (draft 06). >=20 > Combining the comments from this thread about sec 6, here is the = proposed new first paragraph: >=20 > A large range of threats can be mitigated by protecting the content > of the token, for example using a digital signature or a keyed > message digest. Alternatively, the content of the token could be > passed by reference rather than by value (requiring a separate > message exchange to resolve the reference to the token content). = To > simplify the subsequent description we assume in the PoP = architecture > that the token itself is integrity protected by the authorization > server and the token remains opaque to the client. The token = itself > cannot be modified by the client, either due to cryptographic > protection (such as signature or encryption) or use of a reference > value with sufficient entropy and associated secure lookup. These > are characteristics shared with bearer tokens and more information = on > best practices can be found in [RFC6819] and in the security > considerations section of [RFC6750]. > If this looks good to the group, I=E2=80=99ll post draft 7 this = afternoon (pacific). >=20 > Thanks, >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >> On Nov 25, 2015, at 2:19 PM, Kathleen Moriarty = > wrote: >>=20 >>=20 >>=20 >> On Wed, Nov 25, 2015 at 3:58 PM, John Bradley > wrote: >> I am fine with that, however saying integrity protected, may be = better than signed. May people will argue that HMAC or encryption with = sender verification is not signature. >>=20 >> Good point, I also prefer integrity protected. Are we all good with = this now? I'd like to look at a diff to make sure after following the = thread. >>=20 >> Thanks! >> Kathleen >>=20 >> =20 >> However they are perfectly valid. >>=20 >>=20 >>> On Nov 25, 2015, at 5:53 PM, Justin Richer > wrote: >>>=20 >>> The requirement is not that signed JWTs be used, it=E2=80=99s that = unsigned JWTs not be used on their own. Reference tokens and encrypted = JWTs are also valid, as are other signed formats like SAML assertions or = even a COSE Token (if it=E2=80=99s encoded to HTTP friendliness).=20 >>>=20 >>> My recommendation: >>>=20 >>> Remove the erroneous requirement text from section 5 and restore to = previous version. >>>=20 >>> Amend the text in section 6 from: >>>=20 >>> To >>> simplify the subsequent description we assume in the PoP = architecture >>> that the token itself is digitally signed by the authorization = server >>> and therefore cannot be modified. >>>=20 >>>=20 >>> To: >>>=20 >>> In all such cases, the token remains opaque to the client. To >>> simplify the subsequent example and description we assume in the = PoP architecture >>> that the token itself cannot be modified by the client, either = due to >>> cryptographic protection (such as signature or encryption) or use = of=20 >>> a reference value with sufficient entropy and associated secure = lookup. >>> These are characteristics shared with bearer tokens and more = information >>> on best practices can be found in [[RFC6819]] and in the security=20= >>> considerations section of [[RFC6750]].=20 >>>=20 >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Nov 25, 2015, at 3:39 PM, Kathleen Moriarty = > wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> On Nov 25, 2015, at 3:20 PM, John Bradley > wrote: >>>>=20 >>>>> Tokens are signed or the information is otherwise integrity = protected between the AS and the RS. =20 >>>>>=20 >>>>> I suspect Kathleen is concerned about the key getting modified in = transit. =20 >>>>> That needs to be protected against, but there is more than one way = to do that. >>>>=20 >>>> Phil is correct. I was looking for consistency between the = sections since they related to each other. If there is a security risk = or consideration, that needs to be explicitly called out as a concern = such as a key being modified in transit. If there are options to = protect against that, those would ideally be required or would have = warnings. >>>>>=20 >>>>> So sending the public key in a unsigned JWT access token would be = immensely stupid, not just for PoP but for scopes and everything else. >>>>=20 >>>> Good, easy to require then. >>>>=20 >>>> Thanks, >>>> Kathleen=20 >>>>>=20 >>>>> In OAuth 2 all tokens need to be integrity protected between the = AS and RS. =20 >>>>> That can be via signature, by having a reference with sufficient = entropy and secure introspection or database lookup. >>>>>=20 >>>>> I think that is a OAuth 2 security consideration. We are adding = a additional confirmation claim to the existing information that needs = to be protected the same as the rest. >>>>>=20 >>>>> John B. >>>>>=20 >>>>>=20 >>>>>> On Nov 25, 2015, at 4:38 PM, Phil Hunt > wrote: >>>>>>=20 >>>>>> >>>>>> If there is agreement that tokens are opaque then the requirement = that tokens be signed must be removed from the threat mitigation = requirements.=20 >>>>>>=20 >>>>>> And the paragraph in sec 5 that brian was concerned about be = restored.=20 >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> On Nov 25, 2015, at 11:24, Justin Richer > wrote: >>>>>>=20 >>>>>>> It is still end to end authentication with opaque tokens =E2=80=94= since all OAuth tokens, including PoP tokens, have always been intended = to be opaque to the client. That hasn=E2=80=99t changed and that isn=E2=80= =99t the intent of this document. If that=E2=80=99s how people are = reading it then we need to pull it back and rewrite it so that=E2=80=99s = not the case. >>>>>>>=20 >>>>>>> The client gets a token that has two parts: the token and the = key. The token is analogous to the access_token we have today and would = come out of the server in the same field. The key is handed to the = client alongside the token or registered by the client during the token = request. Either way there=E2=80=99s an association between the two but = it=E2=80=99s not the same association as a public/private keypair.=20 >>>>>>>=20 >>>>>>> It=E2=80=99s possible to sign the token itself, but the client = doesn=E2=80=99t care. It sends the token and signs the HTTP request to = the RS whether the token is signed, unsigned, hex blob, encrypted, or = anything else. The same series of options are available as with bearer = tokens. PoP tokens have never, ever been intended to be anything but = opaque to the client. >>>>>>>=20 >>>>>>> The token can=E2=80=99t be opaque to the RS, which has to figure = out what key to use to check the message signature. But we=E2=80=99ve = got options there, like the embedded key in a JWT from Mike=E2=80=99s = draft, or doing introspection to get the key (from an extension that = hasn=E2=80=99t been written yet), or simply looking it up in the same = database because the RS and the AS are in the same box. Does this = structure/service/database choice sound familiar? It should, it=E2=80=99s = the same as bearer tokens. This is also how the RS gets information like = which scopes are associated with the token, if it=E2=80=99s expired, and = all that.=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> So here=E2=80=99s how I see it going on the wire: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> (I just wrote this up so there are probably holes. Here=E2=80=99s = the source if anyone wants to tweak it: = http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW50IGFzIEMKA= AwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3R= lY3RlZABICmFzIFJTCgoKClJPLS0 = -QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmV= jdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAK= QcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADA= FKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIA= E8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmN= sdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduY= XR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwB= iBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZ= CkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4= OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&= s=3Dmodern-blue ) >>>>>>>=20 >>>>>>> The client is oblivious to the token just like always. This is = intentional. The RS has the same options to figure out how to process = the token. >>>>>>>=20 >>>>>>> =E2=80=94 Justin >>>>>>>=20 >>>>>>>> On Nov 25, 2015, at 2:03 PM, Phil Hunt > wrote: >>>>>>>>=20 >>>>>>>> Folks,=20 >>>>>>>>=20 >>>>>>>> >>>>>>>> I did not want to go here either. :-) >>>>>>>>=20 >>>>>>>> I don=E2=80=99t read sec 6 as examples. I believe this may = stem from the pop-architecture documents having a dual role as both = =E2=80=9Carchitecture=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D. Maybe we = should clarify the purpose of the document? >>>>>>>>=20 >>>>>>>> I believe section 6 is talking about threat mitigation = assumptions based on the examples that need to be implemented. I am = assuming these are requirements that the other specifications SHOULD = implement. >>>>>>>>=20 >>>>>>>> >>>>>>>> I do not believe we have discussed Opaque PoP tokens and any = inherent risks because the client is not or is unable to validate the = authenticity of the token. Does this introduce the possibility of a = MITM attack where a client can be convinced to sign requests for an = attacker? >>>>>>>>=20 >>>>>>>> If we want to include opaque PoP, I think we need to take a = pause and consider / discuss any threats here. >>>>>>>>=20 >>>>>>>> I find the desire for opaque PoP tokens to be a bit = contradictory. If we=E2=80=99re saying we don=E2=80=99t want to trust = TLS alone (e.g. because of load-balancer termination), why would we then = say, but we are perfectly willing to accept it worked for the OAuth AS = exchanges? Maybe I was very wrong here, but my assumption all along is = that for PoP we=E2=80=99re talking about end-to-end authentication of = all parties except in the case of 3.3 where we simply want to protect an = access token over a non-TLS HTTP connection. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> @independentid >>>>>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>>>>> On Nov 25, 2015, at 10:48 AM, Brian Campbell = > wrote: >>>>>>>>>=20 >>>>>>>>> While I can't say I disagree with the deeper existential = questions about the draft that Justin raises, I was trying not to go = there and rather just point out concerns with the newly added text.=20 >>>>>>>>>=20 >>>>>>>>> The text Phil cites from Sec 6 doesn't say the client must be = able to parse and verify the token. It's an assumption to simplify the = examples that follow and still the token is opaque to the client. I = reread the whole draft (reluctantly) and there's nothing that says the = token has to be non-opaque to the client. And it does talk about = reference style tokens and encrypted tokens, both of which rely on the = opaqueness to the client.=20 >>>>>>>>>=20 >>>>>>>>> On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer = > wrote: >>>>>>>>> Right, I read that as text for describing the examples and not = for describing requirements. >>>>>>>>>=20 >>>>>>>>> The token itself doesn=E2=80=99t have to be signed at all. >>>>>>>>>=20 >>>>>>>>> =E2=80=94 Justin >>>>>>>>>=20 >>>>>>>>>> On Nov 25, 2015, at 1:05 PM, Phil Hunt > wrote: >>>>>>>>>>=20 >>>>>>>>>> Ok. Well this was requested by Kathleen because of this = paragraph in Sec 6.=E2=80=A6 >>>>>>>>>>=20 >>>>>>>>>> To simplify the subsequent description we assume in the = PoP architecture >>>>>>>>>> that the token itself is digitally signed by the = authorization server >>>>>>>>>> and therefore cannot be modified. >>>>>>>>>>=20 >>>>>>>>>> Please=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>> @independentid >>>>>>>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>>>>>>> On Nov 25, 2015, at 9:33 AM, Justin Richer > wrote: >>>>>>>>>>>=20 >>>>>>>>>>> The token doesn=E2=80=99t have to be signed and the client = doesn=E2=80=99t have to verify the signature on the token. That=E2=80=99s = not PoP. The request has to be signed in a way that includes the token. = The token itself can still be opaque. The *key* material can=E2=80=99t = be opaque to the client, but the *token* material still is. >>>>>>>>>>>=20 >>>>>>>>>>> I agree with Brian that this statement is misleading. >>>>>>>>>>>=20 >>>>>>>>>>> The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one style. >>>>>>>>>>>=20 >>>>>>>>>>> What=E2=80=99s most difficult about this particular spec is = that it=E2=80=99s very hand-wavy, saying =E2=80=9Cthis is kinda a thing = that kinda works like this=E2=80=9D without saying how to actually do = it. I=E2=80=99m honestly not sure it=E2=80=99s worth publishing as an = RFC in its own right but I=E2=80=99m not going to stand in its way. >>>>>>>>>>>=20 >>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>=20 >>>>>>>>>>>> On Nov 25, 2015, at 12:14 PM, Brian Campbell = > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> Where does it say that?=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt = > wrote: >>>>>>>>>>>> Except that later on we require the token be signed and the = client verify that signed token. IOW mutual pop.=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Phil >>>>>>>>>>>>=20 >>>>>>>>>>>> On Nov 25, 2015, at 07:30, Brian Campbell = > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Looking at the diff I noticed the following new text, = which seems to conflate bearer/PoP and opaqueness to the client. A = client demonstrating proof-of-possession of some key is orthogonal to = the client being able to parse and understand the access token itself.=20= >>>>>>>>>>>>> =20 >>>>>>>>>>>>> "In contrast to bearer tokens [RFC6750] which call for = tokens that are opaque to OAuth 2.0 clients, this specification defines = the requirements for proof-of-possession ("PoP") tokens that may be = parsed and verified by OAuth 2.0 clients and relying parties." >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt = > wrote: >>>>>>>>>>>>> This draft addresses review comments from Kathleen and = Erik raised since the last draft. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> It may not include some of the discussion from = yesterday/today. I will add that as the group decides. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Phil >>>>>>>>>>>>>=20 >>>>>>>>>>>>> @independentid >>>>>>>>>>>>> www.independentid.com >>>>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>>>=20 >>>>>>>>>>>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org = wrote: >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>>>>>>>> > This draft is a work item of the Web Authorization = Protocol Working Group of the IETF. >>>>>>>>>>>>> > >>>>>>>>>>>>> > Title : OAuth 2.0 Proof-of-Possession = (PoP) Security Architecture >>>>>>>>>>>>> > Authors : Phil Hunt >>>>>>>>>>>>> > Justin Richer >>>>>>>>>>>>> > William Mills >>>>>>>>>>>>> > Prateek Mishra >>>>>>>>>>>>> > Hannes Tschofenig >>>>>>>>>>>>> > Filename : = draft-ietf-oauth-pop-architecture-06.txt >>>>>>>>>>>>> > Pages : 23 >>>>>>>>>>>>> > Date : 2015-11-24 >>>>>>>>>>>>> > >>>>>>>>>>>>> > 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 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. >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > The IETF datatracker status page for this draft is: >>>>>>>>>>>>> > = https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ = >>>>>>>>>>>>> > >>>>>>>>>>>>> > There's also a htmlized version available at: >>>>>>>>>>>>> > = https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 = >>>>>>>>>>>>> > >>>>>>>>>>>>> > A diff from the previous version is available at: >>>>>>>>>>>>> > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 = = >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > 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 . >>>>>>>>>>>>> > >>>>>>>>>>>>> > Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>>>> > ftp://ftp.ietf.org/internet-drafts/ = >>>>>>>>>>>>> > >>>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>>> > OAuth mailing list >>>>>>>>>>>>> > OAuth@ietf.org >>>>>>>>>>>>> > https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> --=20 >>>>>>>>>>>>> =09 >>>>>>>>>>>>> Brian Campbell >>>>>>>>>>>>> Distinguished Engineer >>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>>>> @pingidentity >>>>>>>>>>>>> Connect with us! >>>>>>>>>>>>> = >>>>>>>>>>>>> = = = = = = = = = >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> --=20 >>>>>>>>>>>> =09 >>>>>>>>>>>> Brian Campbell >>>>>>>>>>>> Distinguished Engineer >>>>>>>>>>>> Ping Identity >>>>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>>> @pingidentity >>>>>>>>>>>> Connect with us! >>>>>>>>>>>> = >>>>>>>>>>>> = = = = = = = = _____________________________________= __________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> --=20 >>>>>>>>> =09 >>>>>>>>> Brian Campbell >>>>>>>>> Distinguished Engineer >>>>>>>>> Ping Identity >>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>> +1 720.317.2061 >>>>>>>>> @pingidentity >>>>>>>>> Connect with us! >>>>>>>>> = >>>>>>>>> = = = = = = = = >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>=20 >>=20 >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_5809D437-FEBA-47E9-A7C1-9F9688B5A550 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That=E2=80=99s much better. I would also suggest that a few = edits to hammer home that this is an example

 A large range of threats can be mitigated by protecting the =
content
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).  To
   simplify discussion in the following example we assume=20
   that the token itself [=E2=80=A6]
   cannot be modified by the client, either due to cryptographic
   protection (such as signature or encryption) or use of a reference
   value with sufficient entropy and associated secure lookup.  =
The token remains =
opaque to the client.
These
   are characteristics shared with bearer tokens and more information on
   best practices can be found in [RFC6819] and in the security
   considerations section of =
[RFC6750].

That=E2=80=99s really what=E2=80=99s going on by my read. = Thoughts?

 =E2=80=94 Justin

On = Dec 1, 2015, at 1:08 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

I=E2=80=99ve = reviewed the comments from John, Justin and Kathleen. As suggested, I = plan to remove the erroneous first paragraph in section 5 (draft = 06).

Combining the = comments from this thread about sec 6, here is the proposed new first = paragraph:

 A =
large range of threats can be mitigated by protecting the content
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).  To
   simplify the subsequent description we assume in the PoP architecture
   that the token itself is integrity protected by the authorization
   server and the token remains opaque to the client.  The token itself
   cannot be modified by the client, either due to cryptographic
   protection (such as signature or encryption) or use of a reference
   value with sufficient entropy and associated secure lookup.  These
   are characteristics shared with bearer tokens and more information on
   best practices can be found in [RFC6819] and in the security
   considerations section of [RFC6750].
If this = looks good to the group, I=E2=80=99ll post draft 7 this afternoon = (pacific).

Thanks,


On Nov 25, 2015, at 2:19 PM, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> wrote:



On Wed, Nov 25, 2015 at 3:58 PM, John Bradley = <ve7jtb@ve7jtb.com> wrote:
I am fine with that, however = saying integrity protected, may be better than signed.  May people = will argue that HMAC or encryption with sender verification is not = signature.

Good point, I also prefer integrity protected.  Are we = all good with this now?  I'd like to look at a diff to make sure = after following the thread.

Thanks!
Kathleen
 
However they are perfectly valid.


On Nov 25, 2015, at 5:53 PM, Justin Richer = <jricher@mit.edu> wrote:

The = requirement is not that signed JWTs be used, it=E2=80=99s that unsigned = JWTs not be used on their own. Reference tokens and encrypted JWTs are = also valid, as are other signed formats like SAML assertions or even a = COSE Token (if it=E2=80=99s encoded to HTTP friendliness). 

My = recommendation:

Remove the erroneous requirement text from section 5 and = restore to previous version.

Amend the text in section 6 = from:

   To
   simplify the subsequent description we assume in the PoP architecture

   that the token itself is digitally signed by =
the authorization server
   and therefore cannot be modified.


To:

   In all such cases, the token remains =
opaque to the client. To
   simplify the subsequent example and description we assume in the PoP =
architecture
   that the token itself cannot be =
modified by the client, either due to
   =
cryptographic protection (such as signature or encryption) or use =
of 
   a reference value with sufficient =
entropy and associated secure lookup.
   These are =
characteristics shared with bearer tokens and more information
   on best practices can be found in [[RFC6819]] and in the =
security 
   considerations section of =
[[RFC6750]].


 =E2=80=94 = Justin

On Nov 25, 2015, at 3:39 PM, = Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> = wrote:

Hi,

Sent from my iPhone

On = Nov 25, 2015, at 3:20 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Tokens are signed or the information is otherwise integrity = protected between the AS and the RS.  

I suspect Kathleen is concerned about = the key getting modified in transit.   
That needs to be protected against, but there is more than = one way to do that.

Phil is correct.  I was looking for consistency = between the sections since they related to each other.  If there is = a security risk or consideration, that needs to be explicitly called out = as a concern such as a key being modified in transit.  If there are = options to protect against that, those would ideally be required or = would have warnings.

So sending the public key in a unsigned JWT access token = would be immensely stupid,  not just for PoP but for scopes and = everything else.

Good, easy to require then.

Thanks,
Kathleen 

In OAuth 2 all tokens need to be integrity protected between = the AS and RS.  
That can be via signature, =  by having a reference with sufficient entropy and secure = introspection or database lookup.

I think that is a OAuth 2 security = consideration.   We are adding a additional confirmation claim to = the existing information that needs to be protected the same as the = rest.

John = B.


On Nov 25, 2015, at 4:38 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

<editors = hat>
If there is agreement that tokens are = opaque then the requirement that tokens be signed must be removed from = the threat mitigation requirements. 

And the paragraph in sec 5 that brian = was concerned about be restored. 

Phil

On Nov 25, 2015, at 11:24, Justin Richer <jricher@mit.edu> wrote:

It = is still end to end authentication with opaque tokens =E2=80=94 since = all OAuth tokens, including PoP tokens, have always been intended to be = opaque to the client. That hasn=E2=80=99t changed and that isn=E2=80=99t = the intent of this document. If that=E2=80=99s how people are reading it = then we need to pull it back and rewrite it so that=E2=80=99s not the = case.

The client = gets a token that has two parts: the token and the key. The token is = analogous to the access_token we have today and would come out of the = server in the same field. The key is handed to the client alongside the = token or registered by the client during the token request. Either way = there=E2=80=99s an association between the two but it=E2=80=99s not the = same association as a public/private keypair. 

It=E2=80=99s possible to = sign the token itself, but the client doesn=E2=80=99t care. It sends the = token and signs the HTTP request to the RS whether the token is signed, = unsigned, hex blob, encrypted, or anything else. The same series of = options are available as with bearer tokens. PoP tokens have never, ever = been intended to be anything but opaque to the client.

The token can=E2=80=99t = be opaque to the RS, which has to figure out what key to use to check = the message signature. But we=E2=80=99ve got options there, like the = embedded key in a JWT from Mike=E2=80=99s draft, or doing introspection = to get the key (from an extension that hasn=E2=80=99t been written yet), = or simply looking it up in the same database because the RS and the AS = are in the same box. Does this structure/service/database choice sound = familiar? It should, it=E2=80=99s the same as bearer tokens. This is = also how the RS gets information like which scopes are associated with = the token, if it=E2=80=99s expired, and all that. 




So here=E2=80=99s how I see it going on the wire:



3D"http://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DcGFydGljaXBhb=



(I just wrote this up so = there are probably holes. Here=E2=80=99s the source if anyone wants to = tweak it: http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW= 50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZB= UwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPl= JPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAV= BwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcm= VxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsA= EAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUz= ogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVj= awCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludH= Jvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGlj= IG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAI= QoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiBy= ZXR1cm4AhicJ&s=3Dmodern-blue )

The client is oblivious to the token = just like always. This is intentional. The RS has the same options to = figure out how to process the token.

 =E2=80=94 Justin

On Nov 25, 2015, at 2:03 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Folks, 

<editor = hat>
I did not want to go here either. = :-)

I don=E2=80=99= t read sec 6 as examples.  I believe this may stem from the = pop-architecture documents having a dual role as both =E2=80=9Carchitectur= e=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D.  Maybe we should clarify = the purpose of the document?

I believe section 6 is talking about = threat mitigation assumptions based on the examples that need to be = implemented.  I am assuming these are requirements that the other = specifications SHOULD implement.

<personal hat>
I do not believe we have discussed Opaque PoP tokens and any = inherent risks because the client is not or is unable to validate the = authenticity of the token.  Does this introduce the possibility of = a MITM attack where a client can be convinced to sign requests for an = attacker?

If = we want to include opaque PoP, I think we need to take a pause and = consider / discuss any threats here.

I find the desire for opaque PoP tokens = to be a bit contradictory. If we=E2=80=99re saying we don=E2=80=99t want = to trust TLS alone (e.g. because of load-balancer termination), why = would we then say, but we are perfectly willing to accept it worked for = the OAuth AS exchanges?  Maybe I was very wrong here, but my = assumption all along is that for PoP we=E2=80=99re talking about = end-to-end authentication of all parties except in the case of 3.3 where = we simply want to protect an access token over a non-TLS HTTP = connection.



On Nov 25, 2015, at 10:48 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

While I can't say I disagree with the deeper = existential questions about the draft that Justin raises, I was trying = not to go there and rather just point out concerns with the newly added = text.

The text Phil cites from Sec 6 = doesn't say the client must be able to parse and verify the token. It's = an assumption to simplify the examples that follow and still the token = is opaque to the client. I reread the whole draft (reluctantly) and = there's nothing that says the token has to be non-opaque to the client. = And it does talk about reference style tokens and encrypted tokens, both = of which rely on the opaqueness to the client.

On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer = <jricher@mit.edu> wrote:
Right, I read that as text for = describing the examples and not for describing requirements.

The token itself = doesn=E2=80=99t have to be signed at all.

 =E2=80=94 Justin

On Nov 25, 2015, at 1:05 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:

Ok. Well this was = requested by Kathleen because of this paragraph in Sec 6.=E2=80=A6

   =
To simplify the subsequent description we assume in the PoP =
architecture
   =
that the token itself is digitally signed by the authorization server

   and therefore cannot be modified.

Please 

On Nov 25, 2015, at 9:33 AM, Justin Richer <jricher@mit.edu> wrote:

The token = doesn=E2=80=99t have to be signed and the client doesn=E2=80=99t have to = verify the signature on the token. That=E2=80=99s not PoP. The request = has to be signed in a way that includes the token. The token itself can = still be opaque. The *key* material can=E2=80=99t be opaque to the = client, but the *token* material still is.

I agree with Brian that this statement = is misleading.

The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one = style.

What=E2=80= =99s most difficult about this particular spec is that it=E2=80=99s very = hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda works like = this=E2=80=9D without saying how to actually do it. I=E2=80=99m honestly = not sure it=E2=80=99s worth publishing as an RFC in its own right but = I=E2=80=99m not going to stand in its way.

 =E2=80=94 Justin

On Nov 25, 2015, at 12:14 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

Where does it say = that?



On Wed, = Nov 25, 2015 at 8:44 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Except that later on we require the token be = signed and the client verify that signed token. IOW mutual = pop. 

Phil

On Nov 25, 2015, at 07:30, = Brian Campbell <bcampbell@pingidentity.com> = wrote:

Looking at the = diff I noticed the following new text, which seems to conflate = bearer/PoP and opaqueness to the client. A client demonstrating = proof-of-possession of some key is orthogonal to the client being able = to parse and understand the access token itself.
 
"In contrast to bearer tokens [RFC6750] which call for tokens = that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
This draft = addresses review comments from Kathleen and Erik raised since the last = draft.

It may not include some of the discussion from yesterday/today.  I = will add that as the group decides.

Cheers,

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF.
>
>        Title          =  : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors        =  : Phil Hunt
>                  =         Justin Richer
>                  =         William Mills
>                  =         Prateek Mishra
>                  =         Hannes Tschofenig
>       Filename        : = draft-ietf-oauth-pop-architecture-06.txt
>       Pages          =  : 23
>       Date          =   : 2015-11-24
>
> 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 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.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth






--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


________________________________= _______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
________________________________= _______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





--

Best regards,
Kathleen
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_5809D437-FEBA-47E9-A7C1-9F9688B5A550-- From nobody Tue Dec 1 10:29:17 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF741B2EB4 for ; Tue, 1 Dec 2015 10:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLQCF6K6vFsb for ; Tue, 1 Dec 2015 10:29:02 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9021B2EBC for ; Tue, 1 Dec 2015 10:29:01 -0800 (PST) Received: by wmuu63 with SMTP id u63so184961977wmu.0 for ; Tue, 01 Dec 2015 10:29:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j+A+x/Ni3JbjnFRv0217aIyFbJAna7TBosO6PE6rarA=; b=eN+7PdxEvZQliHIdPWpCIxBtsJFtJOAW5SKvMTdR57NuSFLn0JjhBH6g3tU9mmD1zw lFuDinldQjghx2oTCXhlguRTx9BmA8CUH3/l6d0/NSbOvOi9+mxQURn0QngGtmVTSrT3 t7Cccj9x016ZQ90QujO60kQh9k4NNlbSp3Rg9NhEWcndJcpDrrGAV15X+K2HtX8EUu28 dIdG7xIHKvjtJL/f9D9uk9I2/W0zQn3QBFbUWlozUyEFLlMLnhj4/ofczwGzcaebS3x+ 8oi0jHGRCPUkyCZbiKNnCeVslqQdAmhuvt4vEOMFGIC2/c+Nl6sohwSLKtj+zgkK6GCM aEqw== MIME-Version: 1.0 X-Received: by 10.194.222.195 with SMTP id qo3mr40595364wjc.51.1448994540109; Tue, 01 Dec 2015 10:29:00 -0800 (PST) Received: by 10.28.52.130 with HTTP; Tue, 1 Dec 2015 10:28:59 -0800 (PST) In-Reply-To: <8F038A71-C047-42F6-9BA9-D697A14902E1@mit.edu> References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> <1AD1F44B-9837-4288-9997-5292F1DBE30E@oracle.com> <9E20E73C-AC35-4E03-A011-119A32CD0BF1@ve7jtb.com> <7431079B-818C-46E9-8102-D193E49384B2@gmail.com> <638FA321-4DE1-467C-9B5C-3BEA0EC3EB0F@mit.edu> <207E620F-97AA-4851-8776-2A7B1921D58A@ve7jtb.com> <8F038A71-C047-42F6-9BA9-D697A14902E1@mit.edu> Date: Tue, 1 Dec 2015 13:28:59 -0500 Message-ID: From: Kathleen Moriarty To: Justin Richer Content-Type: multipart/alternative; boundary=001a11c3babed84a230525da5452 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 18:29:16 -0000 --001a11c3babed84a230525da5452 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The changes work for me, thanks. On Tue, Dec 1, 2015 at 1:27 PM, Justin Richer wrote: > That=E2=80=99s much better. I would also suggest that a few edits to hamm= er home > that this is an example > > A large range of threats can be mitigated by protecting the content > of the token, for example using a digital signature or a keyed > message digest. Alternatively, the content of the token could be > passed by reference rather than by value (requiring a separate > message exchange to resolve the reference to the token content). To > simplify *discussion in the following example* we assume > that the token itself *[=E2=80=A6**]* > cannot be modified by the client, either due to cryptographic > protection (such as signature or encryption) or use of a reference > value with sufficient entropy and associated secure lookup. *The toke= n remains opaque to the client.* > > These > are characteristics shared with bearer tokens and more information on > best practices can be found in [RFC6819] and in the security > considerations section of [RFC6750]. > > > That=E2=80=99s really what=E2=80=99s going on by my read. Thoughts? > > =E2=80=94 Justin > > On Dec 1, 2015, at 1:08 PM, Phil Hunt wrote: > > I=E2=80=99ve reviewed the comments from John, Justin and Kathleen. As sug= gested, I > plan to remove the erroneous first paragraph in section 5 (draft 06). > > Combining the comments from this thread about sec 6, here is the proposed > new first paragraph: > > A large range of threats can be mitigated by protecting the content > of the token, for example using a digital signature or a keyed > message digest. Alternatively, the content of the token could be > passed by reference rather than by value (requiring a separate > message exchange to resolve the reference to the token content). To > simplify the subsequent description we assume in the PoP architecture > that the token itself is integrity protected by the authorization > server and the token remains opaque to the client. The token itself > cannot be modified by the client, either due to cryptographic > protection (such as signature or encryption) or use of a reference > value with sufficient entropy and associated secure lookup. These > are characteristics shared with bearer tokens and more information on > best practices can be found in [RFC6819] and in the security > considerations section of [RFC6750]. > > If this looks good to the group, I=E2=80=99ll post draft 7 this afternoon > (pacific). > > Thanks, > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Nov 25, 2015, at 2:19 PM, Kathleen Moriarty < > Kathleen.Moriarty.ietf@gmail.com> wrote: > > > > On Wed, Nov 25, 2015 at 3:58 PM, John Bradley wrote: > >> I am fine with that, however saying integrity protected, may be better >> than signed. May people will argue that HMAC or encryption with sender >> verification is not signature. >> > > Good point, I also prefer integrity protected. Are we all good with this > now? I'd like to look at a diff to make sure after following the thread. > > Thanks! > Kathleen > > > >> However they are perfectly valid. >> >> >> On Nov 25, 2015, at 5:53 PM, Justin Richer wrote: >> >> The requirement is not that signed JWTs be used, it=E2=80=99s that unsig= ned JWTs >> not be used on their own. Reference tokens and encrypted JWTs are also >> valid, as are other signed formats like SAML assertions or even a COSE >> Token (if it=E2=80=99s encoded to HTTP friendliness). >> >> My recommendation: >> >> Remove the erroneous requirement text from section 5 and restore to >> previous version. >> >> Amend the text in section 6 from: >> >> To >> simplify the subsequent description we assume in the PoP architecture >> >> that the token itself is digitally signed by the authorization server >> and therefore cannot be modified. >> >> >> >> To: >> >> In all such cases, the token remains opaque to the client. To >> simplify the subsequent example and description we assume in the PoP = architecture >> >> that the token itself cannot be modified by the client, either due to >> >> cryptographic protection (such as signature or encryption) or use of >> >> a reference value with sufficient entropy and associated secure looku= p. >> >> These are characteristics shared with bearer tokens and more informat= ion >> >> on best practices can be found in [[RFC6819]] and in the security >> >> considerations section of [[RFC6750]]. >> >> >> >> =E2=80=94 Justin >> >> On Nov 25, 2015, at 3:39 PM, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> >> Hi, >> >> Sent from my iPhone >> >> On Nov 25, 2015, at 3:20 PM, John Bradley wrote: >> >> Tokens are signed or the information is otherwise integrity protected >> between the AS and the RS. >> >> I suspect Kathleen is concerned about the key getting modified in >> transit. >> That needs to be protected against, but there is more than one way to do >> that. >> >> >> Phil is correct. I was looking for consistency between the sections >> since they related to each other. If there is a security risk or >> consideration, that needs to be explicitly called out as a concern such = as >> a key being modified in transit. If there are options to protect agains= t >> that, those would ideally be required or would have warnings. >> >> >> So sending the public key in a unsigned JWT access token would be >> immensely stupid, not just for PoP but for scopes and everything else. >> >> >> Good, easy to require then. >> >> Thanks, >> Kathleen >> >> >> In OAuth 2 all tokens need to be integrity protected between the AS and >> RS. >> That can be via signature, by having a reference with sufficient entrop= y >> and secure introspection or database lookup. >> >> I think that is a OAuth 2 security consideration. We are adding a >> additional confirmation claim to the existing information that needs to = be >> protected the same as the rest. >> >> John B. >> >> >> On Nov 25, 2015, at 4:38 PM, Phil Hunt wrote: >> >> >> If there is agreement that tokens are opaque then the requirement that >> tokens be signed must be removed from the threat mitigation requirements= . >> >> And the paragraph in sec 5 that brian was concerned about be restored. >> >> Phil >> >> On Nov 25, 2015, at 11:24, Justin Richer wrote: >> >> It is still end to end authentication with opaque tokens =E2=80=94 since= all >> OAuth tokens, including PoP tokens, have always been intended to be opaq= ue >> to the client. That hasn=E2=80=99t changed and that isn=E2=80=99t the in= tent of this >> document. If that=E2=80=99s how people are reading it then we need to pu= ll it back >> and rewrite it so that=E2=80=99s not the case. >> >> The client gets a token that has two parts: the token and the key. The >> token is analogous to the access_token we have today and would come out = of >> the server in the same field. The key is handed to the client alongside = the >> token or registered by the client during the token request. Either way >> there=E2=80=99s an association between the two but it=E2=80=99s not the = same association as >> a public/private keypair. >> >> It=E2=80=99s possible to sign the token itself, but the client doesn=E2= =80=99t care. It >> sends the token and signs the HTTP request to the RS whether the token i= s >> signed, unsigned, hex blob, encrypted, or anything else. The same series= of >> options are available as with bearer tokens. PoP tokens have never, ever >> been intended to be anything but opaque to the client. >> >> The token can=E2=80=99t be opaque to the RS, which has to figure out wha= t key to >> use to check the message signature. But we=E2=80=99ve got options there,= like the >> embedded key in a JWT from Mike=E2=80=99s draft, or doing introspection = to get the >> key (from an extension that hasn=E2=80=99t been written yet), or simply = looking it >> up in the same database because the RS and the AS are in the same box. D= oes >> this structure/service/database choice sound familiar? It should, it=E2= =80=99s the >> same as bearer tokens. This is also how the RS gets information like whi= ch >> scopes are associated with the token, if it=E2=80=99s expired, and all t= hat. >> >> >> >> >> So here=E2=80=99s how I see it going on the wire: >> >> >> >> [image: >> http://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DcGFydGljaXBhbnQgQ2= xpZW50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAI= QZBUwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPlJP= OiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwB= rCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdW= VzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlb= HMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCB= UQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAd= zaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3= RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoY= XJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUA= gX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4Ahic= J&s=3Dmodern-blue] >> >> >> >> (I just wrote this up so there are probably holes. Here=E2=80=99s the so= urce if >> anyone wants to tweak it: >> http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW50IGFzIEM= KAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3= RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmVjd= CB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAKQcA= PAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADAFKQp= BUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIAE8pIC= Yga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmNsdWRpb= mcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduYXR1cmUg= LyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwBiBkFTOiB= zZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZCkAgwIGZG= F0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4OAIQsCACCB= Ap1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&s=3Dmodern-= blue >> ) >> >> The client is oblivious to the token just like always. This is >> intentional. The RS has the same options to figure out how to process th= e >> token. >> >> =E2=80=94 Justin >> >> On Nov 25, 2015, at 2:03 PM, Phil Hunt wrote: >> >> Folks, >> >> >> I did not want to go here either. :-) >> >> I don=E2=80=99t read sec 6 as examples. I believe this may stem from th= e >> pop-architecture documents having a dual role as both =E2=80=9Carchitect= ure=E2=80=9D and >> =E2=80=9Cuse-case=E2=80=9D. Maybe we should clarify the purpose of the = document? >> >> I believe section 6 is talking about threat mitigation assumptions based >> on the examples that need to be implemented. I am assuming these are >> requirements that the other specifications SHOULD implement. >> >> >> I do not believe we have discussed Opaque PoP tokens and any inherent >> risks because the client is not or is unable to validate the authenticit= y >> of the token. Does this introduce the possibility of a MITM attack wher= e a >> client can be convinced to sign requests for an attacker? >> >> If we want to include opaque PoP, I think we need to take a pause and >> consider / discuss any threats here. >> >> I find the desire for opaque PoP tokens to be a bit contradictory. If >> we=E2=80=99re saying we don=E2=80=99t want to trust TLS alone (e.g. beca= use of >> load-balancer termination), why would we then say, but we are perfectly >> willing to accept it worked for the OAuth AS exchanges? Maybe I was ver= y >> wrong here, but my assumption all along is that for PoP we=E2=80=99re ta= lking about >> end-to-end authentication of all parties except in the case of 3.3 where= we >> simply want to protect an access token over a non-TLS HTTP connection. >> >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> On Nov 25, 2015, at 10:48 AM, Brian Campbell >> wrote: >> >> While I can't say I disagree with the deeper existential questions about >> the draft that Justin raises, I was trying not to go there and rather ju= st >> point out concerns with the newly added text. >> >> The text Phil cites from Sec 6 doesn't say the client must be able to >> parse and verify the token. It's an assumption to simplify the examples >> that follow and still the token is opaque to the client. I reread the wh= ole >> draft (reluctantly) and there's nothing that says the token has to be >> non-opaque to the client. And it does talk about reference style tokens = and >> encrypted tokens, both of which rely on the opaqueness to the client. >> >> On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer wrote: >> >>> Right, I read that as text for describing the examples and not for >>> describing requirements. >>> >>> The token itself doesn=E2=80=99t have to be signed at all. >>> >>> =E2=80=94 Justin >>> >>> On Nov 25, 2015, at 1:05 PM, Phil Hunt wrote: >>> >>> Ok. Well this was requested by Kathleen because of this paragraph in Se= c >>> 6.=E2=80=A6 >>> >>> >>> To simplify the subsequent description we assume in the PoP architec= ture >>> >>> that the token itself is digitally signed by the authorization serve= r >>> >>> and therefore cannot be modified. >>> >>> >>> Please >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> On Nov 25, 2015, at 9:33 AM, Justin Richer wrote: >>> >>> The token doesn=E2=80=99t have to be signed and the client doesn=E2=80= =99t have to >>> verify the signature on the token. That=E2=80=99s not PoP. The request = has to be >>> signed in a way that includes the token. The token itself can still be >>> opaque. The *key* material can=E2=80=99t be opaque to the client, but t= he *token* >>> material still is. >>> >>> I agree with Brian that this statement is misleading. >>> >>> The examples use a signed token but that is absolutely not a >>> requirement. Maybe the examples shouldn=E2=80=99t all use one style. >>> >>> What=E2=80=99s most difficult about this particular spec is that it=E2= =80=99s very >>> hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda works like = this=E2=80=9D >>> without saying how to actually do it. I=E2=80=99m honestly not sure it= =E2=80=99s worth >>> publishing as an RFC in its own right but I=E2=80=99m not going to stan= d in its way. >>> >>> =E2=80=94 Justin >>> >>> On Nov 25, 2015, at 12:14 PM, Brian Campbell >>> wrote: >>> >>> Where does it say that? >>> >>> >>> >>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt wrote= : >>> >>>> Except that later on we require the token be signed and the client >>>> verify that signed token. IOW mutual pop. >>>> >>>> Phil >>>> >>>> On Nov 25, 2015, at 07:30, Brian Campbell >>>> wrote: >>>> >>>> Looking at the diff I noticed the following new text, which seems to >>>> conflate bearer/PoP and opaqueness to the client. A client demonstrati= ng >>>> proof-of-possession of some key is orthogonal to the client being able= to >>>> parse and understand the access token itself. >>>> >>>> "In contrast to bearer tokens [RFC6750] which call for tokens that are >>>> opaque to OAuth 2.0 clients, this specification defines the requiremen= ts >>>> for proof-of-possession ("PoP") tokens that may be parsed and verified= by >>>> OAuth 2.0 clients and relying parties." >>>> >>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt >>>> wrote: >>>> >>>>> This draft addresses review comments from Kathleen and Erik raised >>>>> since the last draft. >>>>> >>>>> It may not include some of the discussion from yesterday/today. I >>>>> will add that as the group decides. >>>>> >>>>> Cheers, >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>> >>>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote: >>>>> > >>>>> > >>>>> > A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> > This draft is a work item of the Web Authorization Protocol Working >>>>> Group of the IETF. >>>>> > >>>>> > Title : OAuth 2.0 Proof-of-Possession (PoP) >>>>> Security Architecture >>>>> > Authors : Phil Hunt >>>>> > Justin Richer >>>>> > William Mills >>>>> > Prateek Mishra >>>>> > Hannes Tschofenig >>>>> > Filename : draft-ietf-oauth-pop-architecture-06.txt >>>>> > Pages : 23 >>>>> > Date : 2015-11-24 >>>>> > >>>>> > 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 b= e >>>>> > 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. >>>>> > >>>>> > >>>>> > The IETF datatracker status page for this draft is: >>>>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ >>>>> > >>>>> > There's also a htmlized version available at: >>>>> > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 >>>>> > >>>>> > A diff from the previous version is available at: >>>>> > >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture= -06 >>>>> > >>>>> > >>>>> > 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= . >>>>> > >>>>> > Internet-Drafts are also available by anonymous FTP at: >>>>> > ftp://ftp.ietf.org/internet-drafts/ >>>>> > >>>>> > _______________________________________________ >>>>> > OAuth mailing list >>>>> > OAuth@ietf.org >>>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>>> >>>> >>>> -- >>>> [image: Ping Identity logo] >>>> Brian Campbell >>>> Distinguished Engineer >>>> Ping Identity >>>> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 [image: >>>> twitter] @pingidentity Connect with us! >>>> [image: pingidentity.com] >>>> >>>> [image: >>>> pingidentity.com] >>>> >>>> [image: twitter logo] >>>> [image: >>>> twitter logo] [image: youtube logo] >>>> [image: LinkedIn logo] >>>> [image: Facebook logo] >>>> [image: Google+ logo] >>>> [image: slideshare >>>> logo] [image: flipboard logo] >>>> [image: rss feed icon] >>>> >>>> >>>> >>> >>> >>> -- >>> [image: Ping Identity logo] >>> Brian Campbell >>> Distinguished Engineer >>> Ping Identity >>> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 [image: >>> twitter] @pingidentity Connect with us! >>> [image: pingidentity.com] >>> >>> [image: >>> pingidentity.com] >>> >>> [image: twitter logo] >>> [image: >>> twitter logo] [image: youtube logo] >>> [image: LinkedIn logo] >>> [image: Facebook logo] >>> [image: Google+ logo] >>> [image: slideshare >>> logo] [image: flipboard logo] >>> [image: rss feed icon] >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >>> >> >> >> -- >> [image: Ping Identity logo] >> Brian Campbell >> Distinguished Engineer >> Ping Identity >> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 [image: >> twitter] @pingidentity Connect with us! >> [image: pingidentity.com] >> >> [image: >> pingidentity.com] >> >> [image: twitter logo] >> [image: >> twitter logo] [image: youtube logo] >> [image: LinkedIn logo] >> [image: Facebook logo] >> [image: Google+ logo] >> [image: slideshare >> logo] [image: flipboard logo] >> [image: rss feed icon] >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> > > > -- > > Best regards, > Kathleen > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --=20 Best regards, Kathleen --001a11c3babed84a230525da5452 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The changes work for me, thanks.

On Tue, Dec 1, 2015 at 1:27 PM, Justi= n Richer <jricher@mit.edu> wrote:
That=E2=80=99s much better. I wou= ld also suggest that a few edits to hammer home that this is an example
 A large range of threats can be mitigated by protecting the content
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).  To
   simplify discussion in the foll=
owing example we assume=20
   that the token itself [=E2=80=A6]
   cannot be modified by the client, either due to cryptographic
   protection (such as signature or encryption) or use of a reference
   value with sufficient entropy and associated secure lookup.  The token remains opaque to the client.
These
   are characteristics shared with bearer tokens and more information on
   best practices can be found in [RFC6819] and in the security
   considerations section of [RFC6750].

<= /span>
That=E2=80=99s really what=E2=80=99s going on by my read. = Thoughts?

=C2=A0=E2=80=94 Justin

On Dec 1, 2015, at 1:08 PM, Phil = Hunt <phil.hun= t@oracle.com> wrote:

I=E2=80=99ve reviewed the comments from= John, Justin and Kathleen. As suggested, I plan to remove the erroneous fi= rst paragraph in section 5 (draft 06).

Combining the com= ments from this thread about sec 6, here is the proposed new first paragrap= h:

 A large range of threats can be mitigated by protecting the cont=
ent
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).  To
   simplify the subsequent description we assume in the PoP architecture
   that the token itself is integrity protected by the authorization
   server and the token remains opaque to the client.  The token itself
   cannot be modified by the client, either due to cryptographic
   protection (such as signature or encryption) or use of a reference
   value with sufficient entropy and associated secure lookup.  These
   are characteristics shared with bearer tokens and more information on
   best practices can be found in [RFC6819] and in the security
   considerations section of [RFC6750].
If this looks good to the= group, I=E2=80=99ll post draft 7 this afternoon (pacific).

<= /div>
Thanks,


On Nov 25, 2015, at 2:19 PM, Kathle= en Moriarty <Kathleen.Moriarty.ietf@gmail.com> wrote:

<= div dir=3D"ltr">

On Wed, Nov 25, 2015 at 3:58 PM, John Bradley <ve7jtb@ve7jtb.com>= ; wrote:
I am fine with that, however saying integrity protected, may be = better than signed.=C2=A0 May people will argue that HMAC or encryption wit= h sender verification is not signature.

Good point, I also prefer integrity protected.=C2=A0 Are we all good wit= h this now?=C2=A0 I'd like to look at a diff to make sure after followi= ng the thread.

Thanks!
Kathleen

=C2=A0
However they are perfectly valid.
=


On Nov 25, 2015= , at 5:53 PM, Justin Richer <jricher@mit.edu> wrote:

The requirement is not that signed JWTs be used, it=E2=80= =99s that unsigned JWTs not be used on their own. Reference tokens and encr= ypted JWTs are also valid, as are other signed formats like SAML assertions= or even a COSE Token (if it=E2=80=99s encoded to HTTP friendliness).=C2=A0=

My recommendation:

Remove the = erroneous requirement text from section 5 and restore to previous version.<= /div>

Amend the text in section 6 from:

   To
   simplify the subsequent description we assume in the PoP architecture

   that the token itself is digitally signed by the authorizatio=
n server
   and therefore cannot be modified.


To:

   In all such cases, the token r=
emains opaque to the client. To
   simplify the subsequent example and description we assume in the PoP arc=
hitecture
   that the token itself cannot be modified by the clie=
nt, either due to
   cryptographic protection (such as signature =
or encryption) or use of=C2=A0
   a reference value with sufficie=
nt entropy and associated secure lookup.
   These are characteris=
tics shared with bearer tokens and more information
   on best pr=
actices can be found in [[RFC6819]] and in the security=C2=A0
   =
considerations section of [[RFC6750]].


=
=C2=A0=E2=80=94 Justin

On Nov 25, 2015, at 3:39 PM, Kathleen Moriarty <kathleen.moriarty.ie= tf@gmail.com> wrote:

Hi,

Sent from my iPhone

On Nov = 25, 2015, at 3:20 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Tokens are signed or the information is otherwise inte= grity protected between the AS and the RS. =C2=A0

I susp= ect Kathleen is concerned about the key getting modified in transit. =C2=A0= =C2=A0
That needs to be protected against, but there is more than= one way to do that.

Phil is correct= .=C2=A0 I was looking for consistency between the sections since they relat= ed to each other.=C2=A0 If there is a security risk or consideration, that = needs to be explicitly called out as a concern such as a key being modified= in transit.=C2=A0 If there are options to protect against that, those woul= d ideally be required or would have warnings.
=

So sending the public key in a unsigned JWT access= token would be immensely stupid, =C2=A0not just for PoP but for scopes and= everything else.

Good, easy to requ= ire then.

Thanks,
Kathleen=C2=A0

In OAuth 2 all tokens need to be i= ntegrity protected between the AS and RS. =C2=A0
That can be via = signature, =C2=A0by having a reference with sufficient entropy and secure i= ntrospection or database lookup.

I think that is a= OAuth 2 security consideration. =C2=A0 We are adding a additional confirma= tion claim to the existing information that needs to be protected the same = as the rest.

John B.


=
On Nov 25, 2015, at 4:38 PM, Phil Hunt = <phil.hunt@ora= cle.com> wrote:

<editors hat= >
If there is agreement that tokens are opaque then the requir= ement that tokens be signed must be removed from the threat mitigation requ= irements.=C2=A0

And the paragraph in sec 5 that br= ian was concerned about be restored.=C2=A0

Phil

On Nov 25, 2015, at 11:24, Justin Richer <jricher@mit.edu> wrote:

It is still end to end authentication wi= th opaque tokens =E2=80=94 since all OAuth tokens, including PoP tokens, ha= ve always been intended to be opaque to the client. That hasn=E2=80=99t cha= nged and that isn=E2=80=99t the intent of this document. If that=E2=80=99s = how people are reading it then we need to pull it back and rewrite it so th= at=E2=80=99s not the case.

The client gets a token that = has two parts: the token and the key. The token is analogous to the access_= token we have today and would come out of the server in the same field. The= key is handed to the client alongside the token or registered by the clien= t during the token request. Either way there=E2=80=99s an association betwe= en the two but it=E2=80=99s not the same association as a public/private ke= ypair.=C2=A0

It=E2=80=99s possible to sign the tok= en itself, but the client doesn=E2=80=99t care. It sends the token and sign= s the HTTP request to the RS whether the token is signed, unsigned, hex blo= b, encrypted, or anything else. The same series of options are available as= with bearer tokens. PoP tokens have never, ever been intended to be anythi= ng but opaque to the client.

The token can=E2=80= =99t be opaque to the RS, which has to figure out what key to use to check = the message signature. But we=E2=80=99ve got options there, like the embedd= ed key in a JWT from Mike=E2=80=99s draft, or doing introspection to get th= e key (from an extension that hasn=E2=80=99t been written yet), or simply l= ooking it up in the same database because the RS and the AS are in the same= box. Does this structure/service/database choice sound familiar? It should= , it=E2=80=99s the same as bearer tokens. This is also how the RS gets info= rmation like which scopes are associated with the token, if it=E2=80=99s ex= pired, and all that.=C2=A0




So here=E2=80=99s how I see it going on the wire:



3D"http://www.=



(I just wrote this up so there are probably holes. Here=E2= =80=99s the source if anyone wants to tweak it:=C2=A0http://www.websequencediagrams.com/?lz= =3DcGFydGljaXBhbnQgQ2xpZW50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRo= b3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28= gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQ= IHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkI= GtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5= cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQU= AcBIKZW5kCgpDLT5SUzogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZA= CBbQYKUlMARAZjaGVjawCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY= 2sAgncFAIIYBWludHJvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAv= BWtleSAocHVibGljIG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwA= tBiBEQikAHQthAIQoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAI= JbBgCCXQVDOiByZXR1cm4AhicJ&s=3Dmodern-blue )

T= he client is oblivious to the token just like always. This is intentional. = The RS has the same options to figure out how to process the token.

=C2=A0=E2=80=94 Justin

On Nov 25, 2015, at 2:03 PM, Phil Hunt <phil.hunt@oracle.com> wrot= e:

Folks,=C2=A0

<edi= tor hat>
I did not want to go here either. :-)

<= /div>
I don=E2=80=99t read sec 6 as examples.=C2=A0 I believe this may = stem from the pop-architecture documents having a dual role as both =E2=80= =9Carchitecture=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D.=C2=A0 Maybe we sho= uld clarify the purpose of the document?

I believe= section 6 is talking about threat mitigation assumptions based on the exam= ples that need to be implemented.=C2=A0 I am assuming these are requirement= s that the other specifications SHOULD implement.

= <personal hat>
I do not believe we have discussed Opaque Po= P tokens and any inherent risks because the client is not or is unable to v= alidate the authenticity of the token.=C2=A0 Does this introduce the possib= ility of a MITM attack where a client can be convinced to sign requests for= an attacker?

If we want to include opaque PoP, I = think we need to take a pause and consider / discuss any threats here.

I find the desire for opaque PoP tokens to be a bit co= ntradictory. If we=E2=80=99re saying we don=E2=80=99t want to trust TLS alo= ne (e.g. because of load-balancer termination), why would we then say, but = we are perfectly willing to accept it worked for the OAuth AS exchanges?=C2= =A0 Maybe I was very wrong here, but my assumption all along is that for Po= P we=E2=80=99re talking about end-to-end authentication of all parties exce= pt in the case of 3.3 where we simply want to protect an access token over = a non-TLS HTTP connection.


On Nov 25, 2015, at 10:48 AM, Brian= Campbell <bcampbell@pingidentity.com> wrote:

While I can't say I disagree with the deeper existential que= stions about the draft that Justin raises, I was trying not to go there and= rather just point out concerns with the newly added text.

Th= e text Phil cites from Sec 6 doesn't say the client must be able to par= se and verify the token. It's an assumption to simplify the examples th= at follow and still the token is opaque to the client. I reread the whole d= raft (reluctantly) and there's nothing that says the token has to be no= n-opaque to the client. And it does talk about reference style tokens and e= ncrypted tokens, both of which rely on the opaqueness to the client.

On Wed,= Nov 25, 2015 at 11:27 AM, Justin Richer <jricher@mit.edu> wro= te:
R= ight, I read that as text for describing the examples and not for describin= g requirements.

The token itself doesn=E2=80=99t have to= be signed at all.

= =C2=A0=E2=80=94 Justin

On Nov 25, 2015, at 1:05 PM, Phil Hunt <phil.hunt@oracle.com>= ; wrote:

Ok. Well this was requested by Kathleen= because of this paragraph in Sec 6.=E2=80=A6

   To simplify the subsequent descripti=
on we assume in the PoP architecture
   that the token itself is digitally signed =
by the authorization server

   and=
 therefore cannot be modified.

Please=C2=A0

On Nov 25, 2015, at 9:33 AM, Justin= Richer <jricher@mi= t.edu> wrote:

The = token doesn=E2=80=99t have to be signed and the client doesn=E2=80=99t have= to verify the signature on the token. That=E2=80=99s not PoP. The request = has to be signed in a way that includes the token. The token itself can sti= ll be opaque. The *key* material can=E2=80=99t be opaque to the client, but= the *token* material still is.

I agree with Brian that = this statement is misleading.

The examples use a sig= ned token but that is absolutely not a requirement. Maybe the examples shou= ldn=E2=80=99t all use one style.

What=E2=80=99s mo= st difficult about this particular spec is that it=E2=80=99s very hand-wavy= , saying =E2=80=9Cthis is kinda a thing that kinda works like this=E2=80=9D= without saying how to actually do it. I=E2=80=99m honestly not sure it=E2= =80=99s worth publishing as an RFC in its own right but I=E2=80=99m not goi= ng to stand in its way.

=C2=A0=E2=80=94 Justin

On Nov 25, 2015, at 12:14 PM= , Brian Campbell <bcampbell@pingidentity.com> wrote:

Where does it say that?



On Wed, Nov 25, 2015 at 8:44 AM, Phil Hu= nt <phil.hunt@oracle.com> wrote:
Except that later on we require the token = be signed and the client verify that signed token. IOW mutual pop.=C2=A0

Phil
<= br>On Nov 25, 2015, at 07:30, Brian Campbell <bcampbell@pingidentity.com> wr= ote:

Looking a= t the diff I noticed the following new text, which seems to conflate bearer= /PoP and opaqueness to the client. A client demonstrating proof-of-possessi= on of some key is orthogonal to the client being able to parse and understa= nd the access token itself.
=C2=A0
"In contrast to bearer token= s [RFC6750] which call for tokens that are opaque to OAuth 2.0 clients, thi= s specification defines the requirements for proof-of-possession ("PoP= ") tokens that may be parsed and verified by OAuth 2.0 clients and rel= ying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt &l= t;phil.hunt@oracl= e.com> wrote:
This draft ad= dresses review comments from Kathleen and Erik raised since the last draft.=

It may not include some of the discussion from yesterday/today.=C2=A0 I wil= l add that as the group decides.

Cheers,

Phil

@independentid
www.independentid.com
phil.hunt@oracle.= com

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Phil Hunt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Justin Richer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 William Mills
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Prateek Mishra
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Hannes Tschofenig
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-oauth-pop-architecture-06.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 23
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2015-11-24
>
> Abstract:
>=C2=A0 =C2=A0The OAuth 2.0 bearer token specification, as defined in RF= C 6750,
>=C2=A0 =C2=A0allows any party in possession of a bearer token (a "= bearer") to get
>=C2=A0 =C2=A0access to the associated resources (without demonstrating = possession
>=C2=A0 =C2=A0of a cryptographic key).=C2=A0 To prevent misuse, bearer t= okens must be
>=C2=A0 =C2=A0protected from disclosure in transit and at rest.
>
>=C2=A0 =C2=A0Some scenarios demand additional security protection where= by a client
>=C2=A0 =C2=A0needs to demonstrate possession of cryptographic keying ma= terial when
>=C2=A0 =C2=A0accessing a protected resource.=C2=A0 This document motiva= tes the
>=C2=A0 =C2=A0development of the OAuth 2.0 proof-of-possession security = mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org= /doc/draft-ietf-oauth-pop-architecture/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/dra= ft-ietf-oauth-pop-architecture-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rf= cdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.<= br> >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@<= /td> <= span style=3D"text-decoration:none;font-family:arial,helvetica,sans-serif;f= ont-weight:normal;font-size:14px;padding:0px 0px 0px 3px">bcampbell@pingidentity.com
3D"phone" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">+1 720.317.2061
3D"twitter" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">@pingidentity
Connect with us!
3D"pingidentity.com"
3D"pingidentity.com" 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@<= /td> <= span style=3D"text-decoration:none;font-family:arial,helvetica,sans-serif;f= ont-weight:normal;font-size:14px;padding:0px 0px 0px 3px">bcampbell@pingidentity.com
3D"phone" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">+1 720.317.2061
3D"twitter" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">@pingidentity
Connect with us!
3D"pingidentity.com"
3D"pingidentity.com" 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth





--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@<= /td> <= span style=3D"text-decoration:none;font-family:arial,helvetica,sans-serif;f= ont-weight:normal;font-size:14px;padding:0px 0px 0px 3px">bcampbell@pingidentity.com
3D"phone" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">+1 720.317.2061
3D"twitter" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">@pingidentity
Connect with us!
3D"pingidentity.com"
3D"pingidentity.com" 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss


_______________________________________________OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailm= an/listinfo/oauth
____________= ___________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf= .org/mailman/listinfo/oauth




--

Be= st regards,
Kathleen
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth maili= ng list
OAuth@ietf.o= rg
https://www.ietf.org/mailman/listinfo/oauth




--
<= br>
Best regards,
Kathleen
--001a11c3babed84a230525da5452-- From nobody Tue Dec 1 10:35:22 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2F21B2E81 for ; Tue, 1 Dec 2015 10:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72GhZyiLlzkV for ; Tue, 1 Dec 2015 10:35:12 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60FD51B2EB3 for ; Tue, 1 Dec 2015 10:35:12 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tB1IZAtB026507 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Dec 2015 18:35:10 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tB1IZAJA009689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Dec 2015 18:35:10 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tB1IZ9AR030303; Tue, 1 Dec 2015 18:35:09 GMT Received: from [10.0.1.22] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Dec 2015 10:35:07 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_F83DD604-28CD-4FE4-B303-1AEEE3C5A138" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Phil Hunt In-Reply-To: Date: Tue, 1 Dec 2015 10:35:06 -0800 Message-Id: <9F9526D9-A32A-4E34-A54D-8CC47A15E862@oracle.com> References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> <1AD1F44B-9837-4288-9997-5292F1DBE30E@oracle.com> <9E20E73C-AC35-4E03-A011-119A32CD0BF1@ve7jtb.com> <7431079B-818C-46E9-8102-D193E49384B2@gmail.com> <638FA321-4DE1-467C-9B5C-3BEA0EC3EB0F@mit.edu> <207E620F-97AA-4851-8776-2A7B1921D58A@ve7jtb.com> <8F038A71-! C047-42F6-9BA9-D697A14902E1@mit.edu> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3096.5) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 18:35:20 -0000 --Apple-Mail=_F83DD604-28CD-4FE4-B303-1AEEE3C5A138 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Justin. Your tweaks look good to me. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Dec 1, 2015, at 10:28 AM, Kathleen Moriarty = wrote: >=20 > The changes work for me, thanks. >=20 > On Tue, Dec 1, 2015 at 1:27 PM, Justin Richer > wrote: > That=E2=80=99s much better. I would also suggest that a few edits to = hammer home that this is an example >=20 >> A large range of threats can be mitigated by protecting the content >> of the token, for example using a digital signature or a keyed >> message digest. Alternatively, the content of the token could be >> passed by reference rather than by value (requiring a separate >> message exchange to resolve the reference to the token content). = To >> simplify discussion in the following example we assume=20 >> that the token itself [=E2=80=A6] >> cannot be modified by the client, either due to cryptographic >> protection (such as signature or encryption) or use of a reference >> value with sufficient entropy and associated secure lookup. The = token remains opaque to the client. >> These >> are characteristics shared with bearer tokens and more information = on >> best practices can be found in [RFC6819] and in the security >> considerations section of [RFC6750]. >=20 > That=E2=80=99s really what=E2=80=99s going on by my read. Thoughts? >=20 > =E2=80=94 Justin >=20 >> On Dec 1, 2015, at 1:08 PM, Phil Hunt > wrote: >>=20 >> I=E2=80=99ve reviewed the comments from John, Justin and Kathleen. As = suggested, I plan to remove the erroneous first paragraph in section 5 = (draft 06). >>=20 >> Combining the comments from this thread about sec 6, here is the = proposed new first paragraph: >>=20 >> A large range of threats can be mitigated by protecting the content >> of the token, for example using a digital signature or a keyed >> message digest. Alternatively, the content of the token could be >> passed by reference rather than by value (requiring a separate >> message exchange to resolve the reference to the token content). = To >> simplify the subsequent description we assume in the PoP = architecture >> that the token itself is integrity protected by the authorization >> server and the token remains opaque to the client. The token = itself >> cannot be modified by the client, either due to cryptographic >> protection (such as signature or encryption) or use of a reference >> value with sufficient entropy and associated secure lookup. These >> are characteristics shared with bearer tokens and more information = on >> best practices can be found in [RFC6819] and in the security >> considerations section of [RFC6750]. >> If this looks good to the group, I=E2=80=99ll post draft 7 this = afternoon (pacific). >>=20 >> Thanks, >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com = phil.hunt@oracle.com = >>> On Nov 25, 2015, at 2:19 PM, Kathleen Moriarty = > wrote: >>>=20 >>>=20 >>>=20 >>> On Wed, Nov 25, 2015 at 3:58 PM, John Bradley > wrote: >>> I am fine with that, however saying integrity protected, may be = better than signed. May people will argue that HMAC or encryption with = sender verification is not signature. >>>=20 >>> Good point, I also prefer integrity protected. Are we all good with = this now? I'd like to look at a diff to make sure after following the = thread. >>>=20 >>> Thanks! >>> Kathleen >>>=20 >>> =20 >>> However they are perfectly valid. >>>=20 >>>=20 >>>> On Nov 25, 2015, at 5:53 PM, Justin Richer > wrote: >>>>=20 >>>> The requirement is not that signed JWTs be used, it=E2=80=99s that = unsigned JWTs not be used on their own. Reference tokens and encrypted = JWTs are also valid, as are other signed formats like SAML assertions or = even a COSE Token (if it=E2=80=99s encoded to HTTP friendliness).=20 >>>>=20 >>>> My recommendation: >>>>=20 >>>> Remove the erroneous requirement text from section 5 and restore to = previous version. >>>>=20 >>>> Amend the text in section 6 from: >>>>=20 >>>> To >>>> simplify the subsequent description we assume in the PoP = architecture >>>> that the token itself is digitally signed by the authorization = server >>>> and therefore cannot be modified. >>>>=20 >>>>=20 >>>> To: >>>>=20 >>>> In all such cases, the token remains opaque to the client. To >>>> simplify the subsequent example and description we assume in the = PoP architecture >>>> that the token itself cannot be modified by the client, either = due to >>>> cryptographic protection (such as signature or encryption) or = use of=20 >>>> a reference value with sufficient entropy and associated secure = lookup. >>>> These are characteristics shared with bearer tokens and more = information >>>> on best practices can be found in [[RFC6819]] and in the = security=20 >>>> considerations section of [[RFC6750]].=20 >>>>=20 >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Nov 25, 2015, at 3:39 PM, Kathleen Moriarty = > wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>> On Nov 25, 2015, at 3:20 PM, John Bradley > wrote: >>>>>=20 >>>>>> Tokens are signed or the information is otherwise integrity = protected between the AS and the RS. =20 >>>>>>=20 >>>>>> I suspect Kathleen is concerned about the key getting modified in = transit. =20 >>>>>> That needs to be protected against, but there is more than one = way to do that. >>>>>=20 >>>>> Phil is correct. I was looking for consistency between the = sections since they related to each other. If there is a security risk = or consideration, that needs to be explicitly called out as a concern = such as a key being modified in transit. If there are options to = protect against that, those would ideally be required or would have = warnings. >>>>>>=20 >>>>>> So sending the public key in a unsigned JWT access token would be = immensely stupid, not just for PoP but for scopes and everything else. >>>>>=20 >>>>> Good, easy to require then. >>>>>=20 >>>>> Thanks, >>>>> Kathleen=20 >>>>>>=20 >>>>>> In OAuth 2 all tokens need to be integrity protected between the = AS and RS. =20 >>>>>> That can be via signature, by having a reference with sufficient = entropy and secure introspection or database lookup. >>>>>>=20 >>>>>> I think that is a OAuth 2 security consideration. We are adding = a additional confirmation claim to the existing information that needs = to be protected the same as the rest. >>>>>>=20 >>>>>> John B. >>>>>>=20 >>>>>>=20 >>>>>>> On Nov 25, 2015, at 4:38 PM, Phil Hunt > wrote: >>>>>>>=20 >>>>>>> >>>>>>> If there is agreement that tokens are opaque then the = requirement that tokens be signed must be removed from the threat = mitigation requirements.=20 >>>>>>>=20 >>>>>>> And the paragraph in sec 5 that brian was concerned about be = restored.=20 >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>> On Nov 25, 2015, at 11:24, Justin Richer > wrote: >>>>>>>=20 >>>>>>>> It is still end to end authentication with opaque tokens =E2=80=94= since all OAuth tokens, including PoP tokens, have always been intended = to be opaque to the client. That hasn=E2=80=99t changed and that isn=E2=80= =99t the intent of this document. If that=E2=80=99s how people are = reading it then we need to pull it back and rewrite it so that=E2=80=99s = not the case. >>>>>>>>=20 >>>>>>>> The client gets a token that has two parts: the token and the = key. The token is analogous to the access_token we have today and would = come out of the server in the same field. The key is handed to the = client alongside the token or registered by the client during the token = request. Either way there=E2=80=99s an association between the two but = it=E2=80=99s not the same association as a public/private keypair.=20 >>>>>>>>=20 >>>>>>>> It=E2=80=99s possible to sign the token itself, but the client = doesn=E2=80=99t care. It sends the token and signs the HTTP request to = the RS whether the token is signed, unsigned, hex blob, encrypted, or = anything else. The same series of options are available as with bearer = tokens. PoP tokens have never, ever been intended to be anything but = opaque to the client. >>>>>>>>=20 >>>>>>>> The token can=E2=80=99t be opaque to the RS, which has to = figure out what key to use to check the message signature. But we=E2=80=99= ve got options there, like the embedded key in a JWT from Mike=E2=80=99s = draft, or doing introspection to get the key (from an extension that = hasn=E2=80=99t been written yet), or simply looking it up in the same = database because the RS and the AS are in the same box. Does this = structure/service/database choice sound familiar? It should, it=E2=80=99s = the same as bearer tokens. This is also how the RS gets information like = which scopes are associated with the token, if it=E2=80=99s expired, and = all that.=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> So here=E2=80=99s how I see it going on the wire: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> (I just wrote this up so there are probably holes. Here=E2=80=99s= the source if anyone wants to tweak it: = http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW50IGFzIEMKA= AwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3R= lY3RlZABICmFzIFJTCgoKClJPLS0 = -QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmV= jdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAK= QcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADA= FKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIA= E8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmN= sdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduY= XR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwB= iBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZ= CkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4= OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&= s=3Dmodern-blue ) >>>>>>>>=20 >>>>>>>> The client is oblivious to the token just like always. This is = intentional. The RS has the same options to figure out how to process = the token. >>>>>>>>=20 >>>>>>>> =E2=80=94 Justin >>>>>>>>=20 >>>>>>>>> On Nov 25, 2015, at 2:03 PM, Phil Hunt > wrote: >>>>>>>>>=20 >>>>>>>>> Folks,=20 >>>>>>>>>=20 >>>>>>>>> >>>>>>>>> I did not want to go here either. :-) >>>>>>>>>=20 >>>>>>>>> I don=E2=80=99t read sec 6 as examples. I believe this may = stem from the pop-architecture documents having a dual role as both = =E2=80=9Carchitecture=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D. Maybe we = should clarify the purpose of the document? >>>>>>>>>=20 >>>>>>>>> I believe section 6 is talking about threat mitigation = assumptions based on the examples that need to be implemented. I am = assuming these are requirements that the other specifications SHOULD = implement. >>>>>>>>>=20 >>>>>>>>> >>>>>>>>> I do not believe we have discussed Opaque PoP tokens and any = inherent risks because the client is not or is unable to validate the = authenticity of the token. Does this introduce the possibility of a = MITM attack where a client can be convinced to sign requests for an = attacker? >>>>>>>>>=20 >>>>>>>>> If we want to include opaque PoP, I think we need to take a = pause and consider / discuss any threats here. >>>>>>>>>=20 >>>>>>>>> I find the desire for opaque PoP tokens to be a bit = contradictory. If we=E2=80=99re saying we don=E2=80=99t want to trust = TLS alone (e.g. because of load-balancer termination), why would we then = say, but we are perfectly willing to accept it worked for the OAuth AS = exchanges? Maybe I was very wrong here, but my assumption all along is = that for PoP we=E2=80=99re talking about end-to-end authentication of = all parties except in the case of 3.3 where we simply want to protect an = access token over a non-TLS HTTP connection. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Phil >>>>>>>>>=20 >>>>>>>>> @independentid >>>>>>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>>>>>> On Nov 25, 2015, at 10:48 AM, Brian Campbell = > wrote: >>>>>>>>>>=20 >>>>>>>>>> While I can't say I disagree with the deeper existential = questions about the draft that Justin raises, I was trying not to go = there and rather just point out concerns with the newly added text.=20 >>>>>>>>>>=20 >>>>>>>>>> The text Phil cites from Sec 6 doesn't say the client must be = able to parse and verify the token. It's an assumption to simplify the = examples that follow and still the token is opaque to the client. I = reread the whole draft (reluctantly) and there's nothing that says the = token has to be non-opaque to the client. And it does talk about = reference style tokens and encrypted tokens, both of which rely on the = opaqueness to the client.=20 >>>>>>>>>>=20 >>>>>>>>>> On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer = > wrote: >>>>>>>>>> Right, I read that as text for describing the examples and = not for describing requirements. >>>>>>>>>>=20 >>>>>>>>>> The token itself doesn=E2=80=99t have to be signed at all. >>>>>>>>>>=20 >>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>=20 >>>>>>>>>>> On Nov 25, 2015, at 1:05 PM, Phil Hunt > wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Ok. Well this was requested by Kathleen because of this = paragraph in Sec 6.=E2=80=A6 >>>>>>>>>>>=20 >>>>>>>>>>> To simplify the subsequent description we assume in the = PoP architecture >>>>>>>>>>> that the token itself is digitally signed by the = authorization server >>>>>>>>>>> and therefore cannot be modified. >>>>>>>>>>>=20 >>>>>>>>>>> Please=20 >>>>>>>>>>> Phil >>>>>>>>>>>=20 >>>>>>>>>>> @independentid >>>>>>>>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>>>>>>>> On Nov 25, 2015, at 9:33 AM, Justin Richer > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> The token doesn=E2=80=99t have to be signed and the client = doesn=E2=80=99t have to verify the signature on the token. That=E2=80=99s = not PoP. The request has to be signed in a way that includes the token. = The token itself can still be opaque. The *key* material can=E2=80=99t = be opaque to the client, but the *token* material still is. >>>>>>>>>>>>=20 >>>>>>>>>>>> I agree with Brian that this statement is misleading. >>>>>>>>>>>>=20 >>>>>>>>>>>> The examples use a signed token but that is absolutely not = a requirement. Maybe the examples shouldn=E2=80=99t all use one style. >>>>>>>>>>>>=20 >>>>>>>>>>>> What=E2=80=99s most difficult about this particular spec is = that it=E2=80=99s very hand-wavy, saying =E2=80=9Cthis is kinda a thing = that kinda works like this=E2=80=9D without saying how to actually do = it. I=E2=80=99m honestly not sure it=E2=80=99s worth publishing as an = RFC in its own right but I=E2=80=99m not going to stand in its way. >>>>>>>>>>>>=20 >>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>=20 >>>>>>>>>>>>> On Nov 25, 2015, at 12:14 PM, Brian Campbell = > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Where does it say that?=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt = > wrote: >>>>>>>>>>>>> Except that later on we require the token be signed and = the client verify that signed token. IOW mutual pop.=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Phil >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Nov 25, 2015, at 07:30, Brian Campbell = > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Looking at the diff I noticed the following new text, = which seems to conflate bearer/PoP and opaqueness to the client. A = client demonstrating proof-of-possession of some key is orthogonal to = the client being able to parse and understand the access token itself.=20= >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> "In contrast to bearer tokens [RFC6750] which call for = tokens that are opaque to OAuth 2.0 clients, this specification defines = the requirements for proof-of-possession ("PoP") tokens that may be = parsed and verified by OAuth 2.0 clients and relying parties." >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt = > wrote: >>>>>>>>>>>>>> This draft addresses review comments from Kathleen and = Erik raised since the last draft. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> It may not include some of the discussion from = yesterday/today. I will add that as the group decides. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Phil >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> @independentid >>>>>>>>>>>>>> www.independentid.com >>>>>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org = wrote: >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>>>>>>>>> > This draft is a work item of the Web Authorization = Protocol Working Group of the IETF. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Title : OAuth 2.0 Proof-of-Possession = (PoP) Security Architecture >>>>>>>>>>>>>> > Authors : Phil Hunt >>>>>>>>>>>>>> > Justin Richer >>>>>>>>>>>>>> > William Mills >>>>>>>>>>>>>> > Prateek Mishra >>>>>>>>>>>>>> > Hannes Tschofenig >>>>>>>>>>>>>> > Filename : = draft-ietf-oauth-pop-architecture-06.txt >>>>>>>>>>>>>> > Pages : 23 >>>>>>>>>>>>>> > Date : 2015-11-24 >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > 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 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. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > The IETF datatracker status page for this draft is: >>>>>>>>>>>>>> > = https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ = >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > There's also a htmlized version available at: >>>>>>>>>>>>>> > = https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 = >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > A diff from the previous version is available at: >>>>>>>>>>>>>> > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 = = >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > 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 . >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>>>>> > ftp://ftp.ietf.org/internet-drafts/ = >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>>>> > OAuth mailing list >>>>>>>>>>>>>> > OAuth@ietf.org >>>>>>>>>>>>>> > https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>> =09= >>>>>>>>>>>>>> Brian Campbell >>>>>>>>>>>>>> Distinguished Engineer >>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>>>>> @pingidentity >>>>>>>>>>>>>> Connect with us! >>>>>>>>>>>>>> = >>>>>>>>>>>>>> = = = = = = = = = >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> --=20 >>>>>>>>>>>>> =09 >>>>>>>>>>>>> Brian Campbell >>>>>>>>>>>>> Distinguished Engineer >>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>>>> @pingidentity >>>>>>>>>>>>> Connect with us! >>>>>>>>>>>>> = >>>>>>>>>>>>> = = = = = = = = = _____________________________________= __________ >>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> --=20 >>>>>>>>>> =09 >>>>>>>>>> Brian Campbell >>>>>>>>>> Distinguished Engineer >>>>>>>>>> Ping Identity >>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>> +1 720.317.2061 >>>>>>>>>> @pingidentity >>>>>>>>>> Connect with us! >>>>>>>>>> = >>>>>>>>>> = = = = = = = = >>>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>>=20 >>> Best regards, >>> Kathleen >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen --Apple-Mail=_F83DD604-28CD-4FE4-B303-1AEEE3C5A138 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Justin. Your tweaks look good to me.


On Dec 1, 2015, at 10:28 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

The changes work for me, thanks.

On Tue, = Dec 1, 2015 at 1:27 PM, Justin Richer <jricher@mit.edu> wrote:
That=E2=80=99s much better. I would also suggest that a few = edits to hammer home that this is an example

 A large range of threats can =
be mitigated by protecting the content
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).  To
   simplify discussion=
 in the following example we assume=20
   that the token itself [=E2=80=A6]
   cannot be modified by the client, either due to cryptographic
   protection (such as signature or encryption) or use of a reference
   value with sufficient entropy and associated secure lookup.  =
The token remains =
opaque to the client.
These
   are characteristics shared with bearer tokens and more information on
   best practices can be found in [RFC6819] and in the security
   considerations section of =
[RFC6750].

That=E2=80=99s really what=E2=80=99s going on by my read. = Thoughts?

 =E2=80= =94 Justin

On Dec 1, 2015, at 1:08 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

I=E2=80=99ve reviewed the = comments from John, Justin and Kathleen. As suggested, I plan to remove = the erroneous first paragraph in section 5 (draft 06).

Combining the comments from this thread = about sec 6, here is the proposed new first paragraph:

 A large =
range of threats can be mitigated by protecting the content
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).  To
   simplify the subsequent description we assume in the PoP architecture
   that the token itself is integrity protected by the authorization
   server and the token remains opaque to the client.  The token itself
   cannot be modified by the client, either due to cryptographic
   protection (such as signature or encryption) or use of a reference
   value with sufficient entropy and associated secure lookup.  These
   are characteristics shared with bearer tokens and more information on
   best practices can be found in [RFC6819] and in the security
   considerations section of [RFC6750].
If this = looks good to the group, I=E2=80=99ll post draft 7 this afternoon = (pacific).

Thanks,


On Nov 25, 2015, at 2:19 PM, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> wrote:



On Wed, = Nov 25, 2015 at 3:58 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I am fine with that, however = saying integrity protected, may be better than signed.  May people = will argue that HMAC or encryption with sender verification is not = signature.

Good point, I also prefer integrity protected.  Are we = all good with this now?  I'd like to look at a diff to make sure = after following the thread.

Thanks!
Kathleen
 
However they are perfectly valid.


On Nov 25, 2015, at 5:53 PM, Justin Richer = <jricher@mit.edu> wrote:

The = requirement is not that signed JWTs be used, it=E2=80=99s that unsigned = JWTs not be used on their own. Reference tokens and encrypted JWTs are = also valid, as are other signed formats like SAML assertions or even a = COSE Token (if it=E2=80=99s encoded to HTTP friendliness). 

My = recommendation:

Remove the erroneous requirement text from section 5 and = restore to previous version.

Amend the text in section 6 = from:

   To
   simplify the subsequent description we assume in the PoP architecture

   that the token itself is digitally signed by =
the authorization server
   and therefore cannot be modified.


To:

   In all such cases, the token remains =
opaque to the client. To
   simplify the subsequent example and description we assume in the PoP =
architecture
   that the token itself cannot be =
modified by the client, either due to
   =
cryptographic protection (such as signature or encryption) or use =
of 
   a reference value with sufficient =
entropy and associated secure lookup.
   These are =
characteristics shared with bearer tokens and more information
   on best practices can be found in [[RFC6819]] and in the =
security 
   considerations section of =
[[RFC6750]].


 =E2=80=94 = Justin

On Nov 25, 2015, at 3:39 PM, = Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> = wrote:

Hi,

Sent from my iPhone

On = Nov 25, 2015, at 3:20 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Tokens are signed or the information is otherwise integrity = protected between the AS and the RS.  

I suspect Kathleen is concerned about = the key getting modified in transit.   
That needs to be protected against, but there is more than = one way to do that.

Phil is correct.  I was looking for consistency = between the sections since they related to each other.  If there is = a security risk or consideration, that needs to be explicitly called out = as a concern such as a key being modified in transit.  If there are = options to protect against that, those would ideally be required or = would have warnings.

So sending the public key in a unsigned JWT access token = would be immensely stupid,  not just for PoP but for scopes and = everything else.

Good, easy to require then.

Thanks,
Kathleen 

In OAuth 2 all tokens need to be integrity protected between = the AS and RS.  
That can be via signature, =  by having a reference with sufficient entropy and secure = introspection or database lookup.

I think that is a OAuth 2 security = consideration.   We are adding a additional confirmation claim to = the existing information that needs to be protected the same as the = rest.

John = B.


On Nov 25, 2015, at 4:38 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

<editors = hat>
If there is agreement that tokens are = opaque then the requirement that tokens be signed must be removed from = the threat mitigation requirements. 

And the paragraph in sec 5 that brian = was concerned about be restored. 

Phil

On Nov 25, 2015, at 11:24, Justin Richer <jricher@mit.edu> wrote:

It = is still end to end authentication with opaque tokens =E2=80=94 since = all OAuth tokens, including PoP tokens, have always been intended to be = opaque to the client. That hasn=E2=80=99t changed and that isn=E2=80=99t = the intent of this document. If that=E2=80=99s how people are reading it = then we need to pull it back and rewrite it so that=E2=80=99s not the = case.

The client = gets a token that has two parts: the token and the key. The token is = analogous to the access_token we have today and would come out of the = server in the same field. The key is handed to the client alongside the = token or registered by the client during the token request. Either way = there=E2=80=99s an association between the two but it=E2=80=99s not the = same association as a public/private keypair. 

It=E2=80=99s possible to = sign the token itself, but the client doesn=E2=80=99t care. It sends the = token and signs the HTTP request to the RS whether the token is signed, = unsigned, hex blob, encrypted, or anything else. The same series of = options are available as with bearer tokens. PoP tokens have never, ever = been intended to be anything but opaque to the client.

The token can=E2=80=99t = be opaque to the RS, which has to figure out what key to use to check = the message signature. But we=E2=80=99ve got options there, like the = embedded key in a JWT from Mike=E2=80=99s draft, or doing introspection = to get the key (from an extension that hasn=E2=80=99t been written yet), = or simply looking it up in the same database because the RS and the AS = are in the same box. Does this structure/service/database choice sound = familiar? It should, it=E2=80=99s the same as bearer tokens. This is = also how the RS gets information like which scopes are associated with = the token, if it=E2=80=99s expired, and all that. 




So here=E2=80=99s how I see it going on the wire:



3D"http://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DcGFydGljaXBhb=



(I just wrote this up so = there are probably holes. Here=E2=80=99s the source if anyone wants to = tweak it: http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW= 50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZB= UwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPl= JPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAV= BwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcm= VxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsA= EAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUz= ogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVj= awCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludH= Jvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGlj= IG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAI= QoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiBy= ZXR1cm4AhicJ&s=3Dmodern-blue )

The client is oblivious to the token = just like always. This is intentional. The RS has the same options to = figure out how to process the token.

 =E2=80=94 Justin

On Nov 25, 2015, at 2:03 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Folks, 

<editor = hat>
I did not want to go here either. = :-)

I don=E2=80=99= t read sec 6 as examples.  I believe this may stem from the = pop-architecture documents having a dual role as both =E2=80=9Carchitectur= e=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D.  Maybe we should clarify = the purpose of the document?

I believe section 6 is talking about = threat mitigation assumptions based on the examples that need to be = implemented.  I am assuming these are requirements that the other = specifications SHOULD implement.

<personal hat>
I do not believe we have discussed Opaque PoP tokens and any = inherent risks because the client is not or is unable to validate the = authenticity of the token.  Does this introduce the possibility of = a MITM attack where a client can be convinced to sign requests for an = attacker?

If = we want to include opaque PoP, I think we need to take a pause and = consider / discuss any threats here.

I find the desire for opaque PoP tokens = to be a bit contradictory. If we=E2=80=99re saying we don=E2=80=99t want = to trust TLS alone (e.g. because of load-balancer termination), why = would we then say, but we are perfectly willing to accept it worked for = the OAuth AS exchanges?  Maybe I was very wrong here, but my = assumption all along is that for PoP we=E2=80=99re talking about = end-to-end authentication of all parties except in the case of 3.3 where = we simply want to protect an access token over a non-TLS HTTP = connection.



On Nov 25, 2015, at 10:48 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

While I can't say I disagree with the deeper = existential questions about the draft that Justin raises, I was trying = not to go there and rather just point out concerns with the newly added = text.

The text Phil cites from Sec 6 = doesn't say the client must be able to parse and verify the token. It's = an assumption to simplify the examples that follow and still the token = is opaque to the client. I reread the whole draft (reluctantly) and = there's nothing that says the token has to be non-opaque to the client. = And it does talk about reference style tokens and encrypted tokens, both = of which rely on the opaqueness to the client.

On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer = <jricher@mit.edu> wrote:
Right, I read that as text for = describing the examples and not for describing requirements.

The token itself = doesn=E2=80=99t have to be signed at all.

 =E2=80=94 Justin

On Nov 25, 2015, at 1:05 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:

Ok. Well this was = requested by Kathleen because of this paragraph in Sec 6.=E2=80=A6

   =
To simplify the subsequent description we assume in the PoP =
architecture
   =
that the token itself is digitally signed by the authorization server

   and therefore cannot be modified.

Please 

On Nov 25, 2015, at 9:33 AM, Justin Richer <jricher@mit.edu> wrote:

The token = doesn=E2=80=99t have to be signed and the client doesn=E2=80=99t have to = verify the signature on the token. That=E2=80=99s not PoP. The request = has to be signed in a way that includes the token. The token itself can = still be opaque. The *key* material can=E2=80=99t be opaque to the = client, but the *token* material still is.

I agree with Brian that this statement = is misleading.

The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one = style.

What=E2=80= =99s most difficult about this particular spec is that it=E2=80=99s very = hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda works like = this=E2=80=9D without saying how to actually do it. I=E2=80=99m honestly = not sure it=E2=80=99s worth publishing as an RFC in its own right but = I=E2=80=99m not going to stand in its way.

 =E2=80=94 Justin

On Nov 25, 2015, at 12:14 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

Where does it say = that?



On Wed, = Nov 25, 2015 at 8:44 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Except that later on we require the token be = signed and the client verify that signed token. IOW mutual = pop. 

Phil

On Nov 25, 2015, at 07:30, = Brian Campbell <bcampbell@pingidentity.com> = wrote:

Looking at the = diff I noticed the following new text, which seems to conflate = bearer/PoP and opaqueness to the client. A client demonstrating = proof-of-possession of some key is orthogonal to the client being able = to parse and understand the access token itself.
 
"In contrast to bearer tokens [RFC6750] which call for tokens = that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
This draft = addresses review comments from Kathleen and Erik raised since the last = draft.

It may not include some of the discussion from yesterday/today.  I = will add that as the group decides.

Cheers,

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF.
>
>        Title          =  : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors        =  : Phil Hunt
>                  =         Justin Richer
>                  =         William Mills
>                  =         Prateek Mishra
>                  =         Hannes Tschofenig
>       Filename        : = draft-ietf-oauth-pop-architecture-06.txt
>       Pages          =  : 23
>       Date          =   : 2015-11-24
>
> 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 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.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth






--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


________________________________= _______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
________________________________= _______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





--

Best regards,
Kathleen
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--

Best regards,
Kathleen

= --Apple-Mail=_F83DD604-28CD-4FE4-B303-1AEEE3C5A138-- From nobody Tue Dec 1 11:18:39 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB01B1B2F1B for ; Tue, 1 Dec 2015 11:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bm9Z6U-_0gcA for ; Tue, 1 Dec 2015 11:18:28 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A90961A1A3D for ; Tue, 1 Dec 2015 11:18:27 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tB1JIPcg021215 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Dec 2015 19:18:26 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tB1JIPwu000799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Dec 2015 19:18:25 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tB1JIOTb021814; Tue, 1 Dec 2015 19:18:24 GMT Received: from [10.0.1.22] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Dec 2015 11:18:22 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_C0B41419-A3BB-48F7-8BD2-ECDE65D434AD" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Phil Hunt In-Reply-To: <9F9526D9-A32A-4E34-A54D-8CC47A15E862@oracle.com> Date: Tue, 1 Dec 2015 11:18:21 -0800 Message-Id: <6636599A-B628-4ABE-88A9-911219501096@oracle.com> References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> <1AD1F44B-9837-4288-9997-5292F1DBE30E@oracle.com> <9E20E73C-AC35-4E03-A011-119A32CD0BF1@ve7jtb.com> <7431079B-818C-46E9-8102-D193E49384B2@gmail.com> <638FA321-4DE1-467C-9B5C-3BEA0EC3EB0F@mit.edu> <207E620F-97AA-4851-8776-2A7B1921D58A@ve7jtb.com> <8F038A71-! ! C047-42F6-9BA9-D697A14902E1@mit.edu> <9F9526D9-A32A-4E34-A54D-8CC47A15E862@oracle.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3096.5) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 19:18:36 -0000 --Apple-Mail=_C0B41419-A3BB-48F7-8BD2-ECDE65D434AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Including Justin=E2=80=99s revision: A large range of threats can be mitigated by protecting the content of the token, for example using a digital signature or a keyed message digest. Alternatively, the content of the token could be passed by reference rather than by value (requiring a separate message exchange to resolve the reference to the token content). To simplify discussion in the following examples, we assume that the token itself is integrity protected by the authorization server and the token remains opaque to the client. The token itself cannot be modified by the client, either due to cryptographic protection (such as signature or encryption) or the use of a reference value with sufficient entropy and associated secure lookup. The token remains opaque to the client. These are characteristics shared with bearer tokens and more information on best practices can be found in [RFC6819] and in the security considerations section of [RFC6750]. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Dec 1, 2015, at 10:35 AM, Phil Hunt wrote: >=20 > Thanks Justin. Your tweaks look good to me. >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >> On Dec 1, 2015, at 10:28 AM, Kathleen Moriarty = > wrote: >>=20 >> The changes work for me, thanks. >>=20 >> On Tue, Dec 1, 2015 at 1:27 PM, Justin Richer > wrote: >> That=E2=80=99s much better. I would also suggest that a few edits to = hammer home that this is an example >>=20 >>> A large range of threats can be mitigated by protecting the content >>> of the token, for example using a digital signature or a keyed >>> message digest. Alternatively, the content of the token could be >>> passed by reference rather than by value (requiring a separate >>> message exchange to resolve the reference to the token content). = To >>> simplify discussion in the following example we assume=20 >>> that the token itself [=E2=80=A6] >>> cannot be modified by the client, either due to cryptographic >>> protection (such as signature or encryption) or use of a = reference >>> value with sufficient entropy and associated secure lookup. The = token remains opaque to the client. >>> These >>> are characteristics shared with bearer tokens and more = information on >>> best practices can be found in [RFC6819] and in the security >>> considerations section of [RFC6750]. >>=20 >> That=E2=80=99s really what=E2=80=99s going on by my read. Thoughts? >>=20 >> =E2=80=94 Justin >>=20 >>> On Dec 1, 2015, at 1:08 PM, Phil Hunt > wrote: >>>=20 >>> I=E2=80=99ve reviewed the comments from John, Justin and Kathleen. = As suggested, I plan to remove the erroneous first paragraph in section = 5 (draft 06). >>>=20 >>> Combining the comments from this thread about sec 6, here is the = proposed new first paragraph: >>>=20 >>> A large range of threats can be mitigated by protecting the content >>> of the token, for example using a digital signature or a keyed >>> message digest. Alternatively, the content of the token could be >>> passed by reference rather than by value (requiring a separate >>> message exchange to resolve the reference to the token content). = To >>> simplify the subsequent description we assume in the PoP = architecture >>> that the token itself is integrity protected by the authorization >>> server and the token remains opaque to the client. The token = itself >>> cannot be modified by the client, either due to cryptographic >>> protection (such as signature or encryption) or use of a = reference >>> value with sufficient entropy and associated secure lookup. = These >>> are characteristics shared with bearer tokens and more = information on >>> best practices can be found in [RFC6819] and in the security >>> considerations section of [RFC6750]. >>> If this looks good to the group, I=E2=80=99ll post draft 7 this = afternoon (pacific). >>>=20 >>> Thanks, >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com = phil.hunt@oracle.com = >>>> On Nov 25, 2015, at 2:19 PM, Kathleen Moriarty = > wrote: >>>>=20 >>>>=20 >>>>=20 >>>> On Wed, Nov 25, 2015 at 3:58 PM, John Bradley > wrote: >>>> I am fine with that, however saying integrity protected, may be = better than signed. May people will argue that HMAC or encryption with = sender verification is not signature. >>>>=20 >>>> Good point, I also prefer integrity protected. Are we all good = with this now? I'd like to look at a diff to make sure after following = the thread. >>>>=20 >>>> Thanks! >>>> Kathleen >>>>=20 >>>> =20 >>>> However they are perfectly valid. >>>>=20 >>>>=20 >>>>> On Nov 25, 2015, at 5:53 PM, Justin Richer > wrote: >>>>>=20 >>>>> The requirement is not that signed JWTs be used, it=E2=80=99s that = unsigned JWTs not be used on their own. Reference tokens and encrypted = JWTs are also valid, as are other signed formats like SAML assertions or = even a COSE Token (if it=E2=80=99s encoded to HTTP friendliness).=20 >>>>>=20 >>>>> My recommendation: >>>>>=20 >>>>> Remove the erroneous requirement text from section 5 and restore = to previous version. >>>>>=20 >>>>> Amend the text in section 6 from: >>>>>=20 >>>>> To >>>>> simplify the subsequent description we assume in the PoP = architecture >>>>> that the token itself is digitally signed by the authorization = server >>>>> and therefore cannot be modified. >>>>>=20 >>>>>=20 >>>>> To: >>>>>=20 >>>>> In all such cases, the token remains opaque to the client. To >>>>> simplify the subsequent example and description we assume in = the PoP architecture >>>>> that the token itself cannot be modified by the client, either = due to >>>>> cryptographic protection (such as signature or encryption) or = use of=20 >>>>> a reference value with sufficient entropy and associated secure = lookup. >>>>> These are characteristics shared with bearer tokens and more = information >>>>> on best practices can be found in [[RFC6819]] and in the = security=20 >>>>> considerations section of [[RFC6750]].=20 >>>>>=20 >>>>>=20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>>> On Nov 25, 2015, at 3:39 PM, Kathleen Moriarty = > wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> Sent from my iPhone >>>>>>=20 >>>>>> On Nov 25, 2015, at 3:20 PM, John Bradley > wrote: >>>>>>=20 >>>>>>> Tokens are signed or the information is otherwise integrity = protected between the AS and the RS. =20 >>>>>>>=20 >>>>>>> I suspect Kathleen is concerned about the key getting modified = in transit. =20 >>>>>>> That needs to be protected against, but there is more than one = way to do that. >>>>>>=20 >>>>>> Phil is correct. I was looking for consistency between the = sections since they related to each other. If there is a security risk = or consideration, that needs to be explicitly called out as a concern = such as a key being modified in transit. If there are options to = protect against that, those would ideally be required or would have = warnings. >>>>>>>=20 >>>>>>> So sending the public key in a unsigned JWT access token would = be immensely stupid, not just for PoP but for scopes and everything = else. >>>>>>=20 >>>>>> Good, easy to require then. >>>>>>=20 >>>>>> Thanks, >>>>>> Kathleen=20 >>>>>>>=20 >>>>>>> In OAuth 2 all tokens need to be integrity protected between the = AS and RS. =20 >>>>>>> That can be via signature, by having a reference with = sufficient entropy and secure introspection or database lookup. >>>>>>>=20 >>>>>>> I think that is a OAuth 2 security consideration. We are = adding a additional confirmation claim to the existing information that = needs to be protected the same as the rest. >>>>>>>=20 >>>>>>> John B. >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Nov 25, 2015, at 4:38 PM, Phil Hunt > wrote: >>>>>>>>=20 >>>>>>>> >>>>>>>> If there is agreement that tokens are opaque then the = requirement that tokens be signed must be removed from the threat = mitigation requirements.=20 >>>>>>>>=20 >>>>>>>> And the paragraph in sec 5 that brian was concerned about be = restored.=20 >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> On Nov 25, 2015, at 11:24, Justin Richer > wrote: >>>>>>>>=20 >>>>>>>>> It is still end to end authentication with opaque tokens =E2=80=94= since all OAuth tokens, including PoP tokens, have always been intended = to be opaque to the client. That hasn=E2=80=99t changed and that isn=E2=80= =99t the intent of this document. If that=E2=80=99s how people are = reading it then we need to pull it back and rewrite it so that=E2=80=99s = not the case. >>>>>>>>>=20 >>>>>>>>> The client gets a token that has two parts: the token and the = key. The token is analogous to the access_token we have today and would = come out of the server in the same field. The key is handed to the = client alongside the token or registered by the client during the token = request. Either way there=E2=80=99s an association between the two but = it=E2=80=99s not the same association as a public/private keypair.=20 >>>>>>>>>=20 >>>>>>>>> It=E2=80=99s possible to sign the token itself, but the client = doesn=E2=80=99t care. It sends the token and signs the HTTP request to = the RS whether the token is signed, unsigned, hex blob, encrypted, or = anything else. The same series of options are available as with bearer = tokens. PoP tokens have never, ever been intended to be anything but = opaque to the client. >>>>>>>>>=20 >>>>>>>>> The token can=E2=80=99t be opaque to the RS, which has to = figure out what key to use to check the message signature. But we=E2=80=99= ve got options there, like the embedded key in a JWT from Mike=E2=80=99s = draft, or doing introspection to get the key (from an extension that = hasn=E2=80=99t been written yet), or simply looking it up in the same = database because the RS and the AS are in the same box. Does this = structure/service/database choice sound familiar? It should, it=E2=80=99s = the same as bearer tokens. This is also how the RS gets information like = which scopes are associated with the token, if it=E2=80=99s expired, and = all that.=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> So here=E2=80=99s how I see it going on the wire: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> (I just wrote this up so there are probably holes. Here=E2=80=99= s the source if anyone wants to tweak it: = http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW50IGFzIEMKA= AwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3R= lY3RlZABICmFzIFJTCgoKClJPLS0 = -QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmV= jdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAK= QcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADA= FKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIA= E8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmN= sdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduY= XR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwB= iBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZ= CkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4= OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&= s=3Dmodern-blue ) >>>>>>>>>=20 >>>>>>>>> The client is oblivious to the token just like always. This is = intentional. The RS has the same options to figure out how to process = the token. >>>>>>>>>=20 >>>>>>>>> =E2=80=94 Justin >>>>>>>>>=20 >>>>>>>>>> On Nov 25, 2015, at 2:03 PM, Phil Hunt > wrote: >>>>>>>>>>=20 >>>>>>>>>> Folks,=20 >>>>>>>>>>=20 >>>>>>>>>> >>>>>>>>>> I did not want to go here either. :-) >>>>>>>>>>=20 >>>>>>>>>> I don=E2=80=99t read sec 6 as examples. I believe this may = stem from the pop-architecture documents having a dual role as both = =E2=80=9Carchitecture=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D. Maybe we = should clarify the purpose of the document? >>>>>>>>>>=20 >>>>>>>>>> I believe section 6 is talking about threat mitigation = assumptions based on the examples that need to be implemented. I am = assuming these are requirements that the other specifications SHOULD = implement. >>>>>>>>>>=20 >>>>>>>>>> >>>>>>>>>> I do not believe we have discussed Opaque PoP tokens and any = inherent risks because the client is not or is unable to validate the = authenticity of the token. Does this introduce the possibility of a = MITM attack where a client can be convinced to sign requests for an = attacker? >>>>>>>>>>=20 >>>>>>>>>> If we want to include opaque PoP, I think we need to take a = pause and consider / discuss any threats here. >>>>>>>>>>=20 >>>>>>>>>> I find the desire for opaque PoP tokens to be a bit = contradictory. If we=E2=80=99re saying we don=E2=80=99t want to trust = TLS alone (e.g. because of load-balancer termination), why would we then = say, but we are perfectly willing to accept it worked for the OAuth AS = exchanges? Maybe I was very wrong here, but my assumption all along is = that for PoP we=E2=80=99re talking about end-to-end authentication of = all parties except in the case of 3.3 where we simply want to protect an = access token over a non-TLS HTTP connection. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>> @independentid >>>>>>>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>>>>>>> On Nov 25, 2015, at 10:48 AM, Brian Campbell = > wrote: >>>>>>>>>>>=20 >>>>>>>>>>> While I can't say I disagree with the deeper existential = questions about the draft that Justin raises, I was trying not to go = there and rather just point out concerns with the newly added text.=20 >>>>>>>>>>>=20 >>>>>>>>>>> The text Phil cites from Sec 6 doesn't say the client must = be able to parse and verify the token. It's an assumption to simplify = the examples that follow and still the token is opaque to the client. I = reread the whole draft (reluctantly) and there's nothing that says the = token has to be non-opaque to the client. And it does talk about = reference style tokens and encrypted tokens, both of which rely on the = opaqueness to the client.=20 >>>>>>>>>>>=20 >>>>>>>>>>> On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer = > wrote: >>>>>>>>>>> Right, I read that as text for describing the examples and = not for describing requirements. >>>>>>>>>>>=20 >>>>>>>>>>> The token itself doesn=E2=80=99t have to be signed at all. >>>>>>>>>>>=20 >>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>=20 >>>>>>>>>>>> On Nov 25, 2015, at 1:05 PM, Phil Hunt = > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> Ok. Well this was requested by Kathleen because of this = paragraph in Sec 6.=E2=80=A6 >>>>>>>>>>>>=20 >>>>>>>>>>>> To simplify the subsequent description we assume in the = PoP architecture >>>>>>>>>>>> that the token itself is digitally signed by the = authorization server >>>>>>>>>>>> and therefore cannot be modified. >>>>>>>>>>>>=20 >>>>>>>>>>>> Please=20 >>>>>>>>>>>> Phil >>>>>>>>>>>>=20 >>>>>>>>>>>> @independentid >>>>>>>>>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>>>>>>>>> On Nov 25, 2015, at 9:33 AM, Justin Richer = > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The token doesn=E2=80=99t have to be signed and the client = doesn=E2=80=99t have to verify the signature on the token. That=E2=80=99s = not PoP. The request has to be signed in a way that includes the token. = The token itself can still be opaque. The *key* material can=E2=80=99t = be opaque to the client, but the *token* material still is. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I agree with Brian that this statement is misleading. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The examples use a signed token but that is absolutely not = a requirement. Maybe the examples shouldn=E2=80=99t all use one style. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> What=E2=80=99s most difficult about this particular spec = is that it=E2=80=99s very hand-wavy, saying =E2=80=9Cthis is kinda a = thing that kinda works like this=E2=80=9D without saying how to actually = do it. I=E2=80=99m honestly not sure it=E2=80=99s worth publishing as an = RFC in its own right but I=E2=80=99m not going to stand in its way. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Nov 25, 2015, at 12:14 PM, Brian Campbell = > wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Where does it say that?=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt = > wrote: >>>>>>>>>>>>>> Except that later on we require the token be signed and = the client verify that signed token. IOW mutual pop.=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Phil >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Nov 25, 2015, at 07:30, Brian Campbell = > wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Looking at the diff I noticed the following new text, = which seems to conflate bearer/PoP and opaqueness to the client. A = client demonstrating proof-of-possession of some key is orthogonal to = the client being able to parse and understand the access token itself.=20= >>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>> "In contrast to bearer tokens [RFC6750] which call for = tokens that are opaque to OAuth 2.0 clients, this specification defines = the requirements for proof-of-possession ("PoP") tokens that may be = parsed and verified by OAuth 2.0 clients and relying parties." >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt = > wrote: >>>>>>>>>>>>>>> This draft addresses review comments from Kathleen and = Erik raised since the last draft. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> It may not include some of the discussion from = yesterday/today. I will add that as the group decides. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Phil >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> @independentid >>>>>>>>>>>>>>> www.independentid.com >>>>>>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org = wrote: >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>>>>>>>>>> > This draft is a work item of the Web Authorization = Protocol Working Group of the IETF. >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > Title : OAuth 2.0 Proof-of-Possession = (PoP) Security Architecture >>>>>>>>>>>>>>> > Authors : Phil Hunt >>>>>>>>>>>>>>> > Justin Richer >>>>>>>>>>>>>>> > William Mills >>>>>>>>>>>>>>> > Prateek Mishra >>>>>>>>>>>>>>> > Hannes Tschofenig >>>>>>>>>>>>>>> > Filename : = draft-ietf-oauth-pop-architecture-06.txt >>>>>>>>>>>>>>> > Pages : 23 >>>>>>>>>>>>>>> > Date : 2015-11-24 >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > 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 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. >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > The IETF datatracker status page for this draft is: >>>>>>>>>>>>>>> > = https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ = >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > There's also a htmlized version available at: >>>>>>>>>>>>>>> > = https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 = >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > A diff from the previous version is available at: >>>>>>>>>>>>>>> > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 = = >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > 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 . >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > Internet-Drafts are also available by anonymous FTP = at: >>>>>>>>>>>>>>> > ftp://ftp.ietf.org/internet-drafts/ = >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>>>>> > OAuth mailing list >>>>>>>>>>>>>>> > OAuth@ietf.org >>>>>>>>>>>>>>> > https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>>> =09= >>>>>>>>>>>>>>> Brian Campbell >>>>>>>>>>>>>>> Distinguished Engineer >>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>>>>>> @pingidentity >>>>>>>>>>>>>>> Connect with us! >>>>>>>>>>>>>>> = >>>>>>>>>>>>>>> = = = = = = = = = >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>> =09= >>>>>>>>>>>>>> Brian Campbell >>>>>>>>>>>>>> Distinguished Engineer >>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>>>>> @pingidentity >>>>>>>>>>>>>> Connect with us! >>>>>>>>>>>>>> = >>>>>>>>>>>>>> = = = = = = = = = _____________________________________= __________ >>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> --=20 >>>>>>>>>>> =09 >>>>>>>>>>> Brian Campbell >>>>>>>>>>> Distinguished Engineer >>>>>>>>>>> Ping Identity >>>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>> @pingidentity >>>>>>>>>>> Connect with us! >>>>>>>>>>> = >>>>>>>>>>> = = = = = = = = >>>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>>=20 >>>> Best regards, >>>> Kathleen >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_C0B41419-A3BB-48F7-8BD2-ECDE65D434AD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Including Justin=E2=80=99s revision:

  A large range of threats can be =
mitigated by protecting the content
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).

   To simplify discussion in the following examples, we assume that the
   token itself is integrity protected by the authorization server and
   the token remains opaque to the client.  The token itself cannot be
   modified by the client, either due to cryptographic protection (such
   as signature or encryption) or the use of a reference value with
   sufficient entropy and associated secure lookup.  The token remains
   opaque to the client.  These are characteristics shared with bearer
   tokens and more information on best practices can be found in
   [RFC6819] and in the security considerations section of [RFC6750].


On Dec 1, 2015, at 10:35 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Thanks Justin. = Your tweaks look good to me.


On Dec 1, 2015, at 10:28 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

The changes work for me, thanks.

On Tue, = Dec 1, 2015 at 1:27 PM, Justin Richer <jricher@mit.edu> wrote:
That=E2=80=99s much better. I would also suggest that a few = edits to hammer home that this is an example

 A large range of threats can =
be mitigated by protecting the content
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).  To
   simplify discussion=
 in the following example we assume=20
   that the token itself [=E2=80=A6]
   cannot be modified by the client, either due to cryptographic
   protection (such as signature or encryption) or use of a reference
   value with sufficient entropy and associated secure lookup.  =
The token remains =
opaque to the client.
These
   are characteristics shared with bearer tokens and more information on
   best practices can be found in [RFC6819] and in the security
   considerations section of =
[RFC6750].

That=E2=80=99s really what=E2=80=99s going on by my read. = Thoughts?

 =E2=80= =94 Justin

On Dec 1, 2015, at 1:08 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

I=E2=80=99ve reviewed the = comments from John, Justin and Kathleen. As suggested, I plan to remove = the erroneous first paragraph in section 5 (draft 06).

Combining the comments from this thread = about sec 6, here is the proposed new first paragraph:

 A large =
range of threats can be mitigated by protecting the content
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).  To
   simplify the subsequent description we assume in the PoP architecture
   that the token itself is integrity protected by the authorization
   server and the token remains opaque to the client.  The token itself
   cannot be modified by the client, either due to cryptographic
   protection (such as signature or encryption) or use of a reference
   value with sufficient entropy and associated secure lookup.  These
   are characteristics shared with bearer tokens and more information on
   best practices can be found in [RFC6819] and in the security
   considerations section of [RFC6750].
If this = looks good to the group, I=E2=80=99ll post draft 7 this afternoon = (pacific).

Thanks,


On Nov 25, 2015, at 2:19 PM, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> wrote:



On Wed, = Nov 25, 2015 at 3:58 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I am fine with that, however = saying integrity protected, may be better than signed.  May people = will argue that HMAC or encryption with sender verification is not = signature.

Good point, I also prefer integrity protected.  Are we = all good with this now?  I'd like to look at a diff to make sure = after following the thread.

Thanks!
Kathleen
 
However they are perfectly valid.


On Nov 25, 2015, at 5:53 PM, Justin Richer = <jricher@mit.edu> wrote:

The = requirement is not that signed JWTs be used, it=E2=80=99s that unsigned = JWTs not be used on their own. Reference tokens and encrypted JWTs are = also valid, as are other signed formats like SAML assertions or even a = COSE Token (if it=E2=80=99s encoded to HTTP friendliness). 

My = recommendation:

Remove the erroneous requirement text from section 5 and = restore to previous version.

Amend the text in section 6 = from:

   To
   simplify the subsequent description we assume in the PoP architecture

   that the token itself is digitally signed by =
the authorization server
   and therefore cannot be modified.


To:

   In all such cases, the token remains =
opaque to the client. To
   simplify the subsequent example and description we assume in the PoP =
architecture
   that the token itself cannot be =
modified by the client, either due to
   =
cryptographic protection (such as signature or encryption) or use =
of 
   a reference value with sufficient =
entropy and associated secure lookup.
   These are =
characteristics shared with bearer tokens and more information
   on best practices can be found in [[RFC6819]] and in the =
security 
   considerations section of =
[[RFC6750]].


 =E2=80=94 = Justin

On Nov 25, 2015, at 3:39 PM, = Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> = wrote:

Hi,

Sent from my iPhone

On = Nov 25, 2015, at 3:20 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Tokens are signed or the information is otherwise integrity = protected between the AS and the RS.  

I suspect Kathleen is concerned about = the key getting modified in transit.   
That needs to be protected against, but there is more than = one way to do that.

Phil is correct.  I was looking for consistency = between the sections since they related to each other.  If there is = a security risk or consideration, that needs to be explicitly called out = as a concern such as a key being modified in transit.  If there are = options to protect against that, those would ideally be required or = would have warnings.

So sending the public key in a unsigned JWT access token = would be immensely stupid,  not just for PoP but for scopes and = everything else.

Good, easy to require then.

Thanks,
Kathleen 

In OAuth 2 all tokens need to be integrity protected between = the AS and RS.  
That can be via signature, =  by having a reference with sufficient entropy and secure = introspection or database lookup.

I think that is a OAuth 2 security = consideration.   We are adding a additional confirmation claim to = the existing information that needs to be protected the same as the = rest.

John = B.


On Nov 25, 2015, at 4:38 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

<editors = hat>
If there is agreement that tokens are = opaque then the requirement that tokens be signed must be removed from = the threat mitigation requirements. 

And the paragraph in sec 5 that brian = was concerned about be restored. 

Phil

On Nov 25, 2015, at 11:24, Justin Richer <jricher@mit.edu> wrote:

It = is still end to end authentication with opaque tokens =E2=80=94 since = all OAuth tokens, including PoP tokens, have always been intended to be = opaque to the client. That hasn=E2=80=99t changed and that isn=E2=80=99t = the intent of this document. If that=E2=80=99s how people are reading it = then we need to pull it back and rewrite it so that=E2=80=99s not the = case.

The client = gets a token that has two parts: the token and the key. The token is = analogous to the access_token we have today and would come out of the = server in the same field. The key is handed to the client alongside the = token or registered by the client during the token request. Either way = there=E2=80=99s an association between the two but it=E2=80=99s not the = same association as a public/private keypair. 

It=E2=80=99s possible to = sign the token itself, but the client doesn=E2=80=99t care. It sends the = token and signs the HTTP request to the RS whether the token is signed, = unsigned, hex blob, encrypted, or anything else. The same series of = options are available as with bearer tokens. PoP tokens have never, ever = been intended to be anything but opaque to the client.

The token can=E2=80=99t = be opaque to the RS, which has to figure out what key to use to check = the message signature. But we=E2=80=99ve got options there, like the = embedded key in a JWT from Mike=E2=80=99s draft, or doing introspection = to get the key (from an extension that hasn=E2=80=99t been written yet), = or simply looking it up in the same database because the RS and the AS = are in the same box. Does this structure/service/database choice sound = familiar? It should, it=E2=80=99s the same as bearer tokens. This is = also how the RS gets information like which scopes are associated with = the token, if it=E2=80=99s expired, and all that. 




So here=E2=80=99s how I see it going on the wire:



3D"http://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DcGFydGljaXBhb=



(I just wrote this up so = there are probably holes. Here=E2=80=99s the source if anyone wants to = tweak it: http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW= 50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZB= UwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPl= JPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAV= BwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcm= VxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsA= EAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUz= ogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVj= awCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludH= Jvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGlj= IG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAI= QoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiBy= ZXR1cm4AhicJ&s=3Dmodern-blue )

The client is oblivious to the token = just like always. This is intentional. The RS has the same options to = figure out how to process the token.

 =E2=80=94 Justin

On Nov 25, 2015, at 2:03 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Folks, 

<editor = hat>
I did not want to go here either. = :-)

I don=E2=80=99= t read sec 6 as examples.  I believe this may stem from the = pop-architecture documents having a dual role as both =E2=80=9Carchitectur= e=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D.  Maybe we should clarify = the purpose of the document?

I believe section 6 is talking about = threat mitigation assumptions based on the examples that need to be = implemented.  I am assuming these are requirements that the other = specifications SHOULD implement.

<personal hat>
I do not believe we have discussed Opaque PoP tokens and any = inherent risks because the client is not or is unable to validate the = authenticity of the token.  Does this introduce the possibility of = a MITM attack where a client can be convinced to sign requests for an = attacker?

If = we want to include opaque PoP, I think we need to take a pause and = consider / discuss any threats here.

I find the desire for opaque PoP tokens = to be a bit contradictory. If we=E2=80=99re saying we don=E2=80=99t want = to trust TLS alone (e.g. because of load-balancer termination), why = would we then say, but we are perfectly willing to accept it worked for = the OAuth AS exchanges?  Maybe I was very wrong here, but my = assumption all along is that for PoP we=E2=80=99re talking about = end-to-end authentication of all parties except in the case of 3.3 where = we simply want to protect an access token over a non-TLS HTTP = connection.



On Nov 25, 2015, at 10:48 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

While I can't say I disagree with the deeper = existential questions about the draft that Justin raises, I was trying = not to go there and rather just point out concerns with the newly added = text.

The text Phil cites from Sec 6 = doesn't say the client must be able to parse and verify the token. It's = an assumption to simplify the examples that follow and still the token = is opaque to the client. I reread the whole draft (reluctantly) and = there's nothing that says the token has to be non-opaque to the client. = And it does talk about reference style tokens and encrypted tokens, both = of which rely on the opaqueness to the client.

On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer = <jricher@mit.edu> wrote:
Right, I read that as text for = describing the examples and not for describing requirements.

The token itself = doesn=E2=80=99t have to be signed at all.

 =E2=80=94 Justin

On Nov 25, 2015, at 1:05 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:

Ok. Well this was = requested by Kathleen because of this paragraph in Sec 6.=E2=80=A6

   =
To simplify the subsequent description we assume in the PoP =
architecture
   =
that the token itself is digitally signed by the authorization server

   and therefore cannot be modified.

Please 

On Nov 25, 2015, at 9:33 AM, Justin Richer <jricher@mit.edu> wrote:

The token = doesn=E2=80=99t have to be signed and the client doesn=E2=80=99t have to = verify the signature on the token. That=E2=80=99s not PoP. The request = has to be signed in a way that includes the token. The token itself can = still be opaque. The *key* material can=E2=80=99t be opaque to the = client, but the *token* material still is.

I agree with Brian that this statement = is misleading.

The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one = style.

What=E2=80= =99s most difficult about this particular spec is that it=E2=80=99s very = hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda works like = this=E2=80=9D without saying how to actually do it. I=E2=80=99m honestly = not sure it=E2=80=99s worth publishing as an RFC in its own right but = I=E2=80=99m not going to stand in its way.

 =E2=80=94 Justin

On Nov 25, 2015, at 12:14 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

Where does it say = that?



On Wed, = Nov 25, 2015 at 8:44 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Except that later on we require the token be = signed and the client verify that signed token. IOW mutual = pop. 

Phil

On Nov 25, 2015, at 07:30, = Brian Campbell <bcampbell@pingidentity.com> = wrote:

Looking at the = diff I noticed the following new text, which seems to conflate = bearer/PoP and opaqueness to the client. A client demonstrating = proof-of-possession of some key is orthogonal to the client being able = to parse and understand the access token itself.
 
"In contrast to bearer tokens [RFC6750] which call for tokens = that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
This draft = addresses review comments from Kathleen and Erik raised since the last = draft.

It may not include some of the discussion from yesterday/today.  I = will add that as the group decides.

Cheers,

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF.
>
>        Title          =  : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors        =  : Phil Hunt
>                  =         Justin Richer
>                  =         William Mills
>                  =         Prateek Mishra
>                  =         Hannes Tschofenig
>       Filename        : = draft-ietf-oauth-pop-architecture-06.txt
>       Pages          =  : 23
>       Date          =   : 2015-11-24
>
> 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 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.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth






--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


________________________________= _______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
________________________________= _______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





--

Best regards,
Kathleen
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--

Best regards,
Kathleen

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_C0B41419-A3BB-48F7-8BD2-ECDE65D434AD-- From nobody Tue Dec 1 11:22:10 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C241B2F55 for ; Tue, 1 Dec 2015 11:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YDWx5wx_irf for ; Tue, 1 Dec 2015 11:21:57 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59D5A1B2F42 for ; Tue, 1 Dec 2015 11:21:56 -0800 (PST) X-AuditID: 1209190e-f79046d0000036c0-b0-565df3528871 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id CA.C1.14016.253FD565; Tue, 1 Dec 2015 14:21:54 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id tB1JLrA9011328; Tue, 1 Dec 2015 14:21:53 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tB1JLp52003911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Dec 2015 14:21:52 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_7DFD03CA-0DF7-4D71-93A7-C502C5B95887" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: <6636599A-B628-4ABE-88A9-911219501096@oracle.com> Date: Tue, 1 Dec 2015 14:21:50 -0500 Message-Id: References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> <1AD1F44B-9837-4288-9997-5292F1DBE30E@oracle.com> <9E20E73C-AC35-4E03-A011-119A32CD0BF1@ve7jtb.com> <7431079B-818C-46E9-8102-D193E49384B2@gmail.com> <638FA321-4DE1-467C-9B5C-3BEA0EC3EB0F@mit.edu> <207E620F-97AA-4851-8776-2A7B1921D58A@ve7jtb.com> <8F038A71-! ! C047- 42F6-9BA9-D697A14902E1@mit.edu> <9F9526D9-A32A-4E34-A54D-8CC47A15E862@oracle.com> <6636599A-B628-4ABE-88A9-911219501096@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsUixG6nohv0OTbM4MJKXouGnfkWJ9++YrNY ML+R3YHZY+esu+weS5b8ZPL4+PQWSwBzFJdNSmpOZllqkb5dAlfG9cn7WAvu32GruDv9BmsD 486vrF2MnBwSAiYSrb82s0HYYhIX7q0Hsrk4hAQWM0m0rNjGDOFsYJToOtLEAuE8YJI4Mn02 WDuzQILE/SevGEFsXgE9iVe3LoPFhQV8JC6efgJmswmoSkxf08IEYnMK2En0PZ0Dto5FQEXi SdcBRog5aRKL7q9hgphjJfF57mkmiGXrOCWamo+CDRIBavh29TojxK2yErt/P2KawCgwC8kd s5DcARHXlli28DUzhK0psb97OQumuIZE57eJrAsY2VYxyqbkVunmJmbmFKcm6xYnJ+blpRbp GuvlZpbopaaUbmIExQKnJN8Oxq8HlQ4xCnAwKvHwSqyNCRNiTSwrrsw9xCjJwaQkyqv+MjZM iC8pP6UyI7E4I76oNCe1+BCjBAezkgjvoudAOd6UxMqq1KJ8mJQ0B4uSOO/cL75hQgLpiSWp 2ampBalFMFkZDg4lCd7+T0CNgkWp6akVaZk5JQhpJg5OkOE8QMOrQWp4iwsSc4sz0yHypxgV pcR55UASAiCJjNI8uF5Qqkp4e9j0FaM40CvCvFc/AlXxANMcXPcroMFMQIM//IkGGVySiJCS amBkOXj46Pao9c+F9IwyeE8vWb2uQ7nGzmbFDjudPUpVteubTtgc6319PHXX9oOMeRVyUsfV 7qVvjJXlv/Z7eoH6TLHHlUVpocKHulVKNaQmtd+68tnKMLDwV4m98FTT99mRijOl5f5UJX99 9Cun70SZzstD3x8YzjtokB0sd9z6ac/EozF6RTxKLMUZiYZazEXFiQDcUDxIMAMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 19:22:08 -0000 --Apple-Mail=_7DFD03CA-0DF7-4D71-93A7-C502C5B95887 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 You=E2=80=99ve got =E2=80=9CThe token remains opaque to the client=E2=80=9D= in there twice now. I had cut out the middle part the first sentence in = the second paragraph below, but that was hard to highlight. If you take = my text as-is that=E2=80=99s what I meant for the edited form. Thanks =E2=80=94 Justin > On Dec 1, 2015, at 2:18 PM, Phil Hunt wrote: >=20 > Including Justin=E2=80=99s revision: >=20 > A large range of threats can be mitigated by protecting the content > of the token, for example using a digital signature or a keyed > message digest. Alternatively, the content of the token could be > passed by reference rather than by value (requiring a separate > message exchange to resolve the reference to the token content). >=20 > To simplify discussion in the following examples, we assume that = the > token itself is integrity protected by the authorization server and > the token remains opaque to the client. The token itself cannot be > modified by the client, either due to cryptographic protection = (such > as signature or encryption) or the use of a reference value with > sufficient entropy and associated secure lookup. The token remains > opaque to the client. These are characteristics shared with bearer > tokens and more information on best practices can be found in > [RFC6819] and in the security considerations section of [RFC6750]. >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >> On Dec 1, 2015, at 10:35 AM, Phil Hunt > wrote: >>=20 >> Thanks Justin. Your tweaks look good to me. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com = phil.hunt@oracle.com = >>> On Dec 1, 2015, at 10:28 AM, Kathleen Moriarty = > wrote: >>>=20 >>> The changes work for me, thanks. >>>=20 >>> On Tue, Dec 1, 2015 at 1:27 PM, Justin Richer > wrote: >>> That=E2=80=99s much better. I would also suggest that a few edits to = hammer home that this is an example >>>=20 >>>> A large range of threats can be mitigated by protecting the = content >>>> of the token, for example using a digital signature or a keyed >>>> message digest. Alternatively, the content of the token could = be >>>> passed by reference rather than by value (requiring a separate >>>> message exchange to resolve the reference to the token content). = To >>>> simplify discussion in the following example we assume=20 >>>> that the token itself [=E2=80=A6] >>>> cannot be modified by the client, either due to cryptographic >>>> protection (such as signature or encryption) or use of a = reference >>>> value with sufficient entropy and associated secure lookup. The = token remains opaque to the client. >>>> These >>>> are characteristics shared with bearer tokens and more = information on >>>> best practices can be found in [RFC6819] and in the security >>>> considerations section of [RFC6750]. >>>=20 >>> That=E2=80=99s really what=E2=80=99s going on by my read. Thoughts? >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Dec 1, 2015, at 1:08 PM, Phil Hunt > wrote: >>>>=20 >>>> I=E2=80=99ve reviewed the comments from John, Justin and Kathleen. = As suggested, I plan to remove the erroneous first paragraph in section = 5 (draft 06). >>>>=20 >>>> Combining the comments from this thread about sec 6, here is the = proposed new first paragraph: >>>>=20 >>>> A large range of threats can be mitigated by protecting the = content >>>> of the token, for example using a digital signature or a keyed >>>> message digest. Alternatively, the content of the token could = be >>>> passed by reference rather than by value (requiring a separate >>>> message exchange to resolve the reference to the token content). = To >>>> simplify the subsequent description we assume in the PoP = architecture >>>> that the token itself is integrity protected by the = authorization >>>> server and the token remains opaque to the client. The token = itself >>>> cannot be modified by the client, either due to cryptographic >>>> protection (such as signature or encryption) or use of a = reference >>>> value with sufficient entropy and associated secure lookup. = These >>>> are characteristics shared with bearer tokens and more = information on >>>> best practices can be found in [RFC6819] and in the security >>>> considerations section of [RFC6750]. >>>> If this looks good to the group, I=E2=80=99ll post draft 7 this = afternoon (pacific). >>>>=20 >>>> Thanks, >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com = phil.hunt@oracle.com = >>>>> On Nov 25, 2015, at 2:19 PM, Kathleen Moriarty = > wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Wed, Nov 25, 2015 at 3:58 PM, John Bradley > wrote: >>>>> I am fine with that, however saying integrity protected, may be = better than signed. May people will argue that HMAC or encryption with = sender verification is not signature. >>>>>=20 >>>>> Good point, I also prefer integrity protected. Are we all good = with this now? I'd like to look at a diff to make sure after following = the thread. >>>>>=20 >>>>> Thanks! >>>>> Kathleen >>>>>=20 >>>>> =20 >>>>> However they are perfectly valid. >>>>>=20 >>>>>=20 >>>>>> On Nov 25, 2015, at 5:53 PM, Justin Richer > wrote: >>>>>>=20 >>>>>> The requirement is not that signed JWTs be used, it=E2=80=99s = that unsigned JWTs not be used on their own. Reference tokens and = encrypted JWTs are also valid, as are other signed formats like SAML = assertions or even a COSE Token (if it=E2=80=99s encoded to HTTP = friendliness).=20 >>>>>>=20 >>>>>> My recommendation: >>>>>>=20 >>>>>> Remove the erroneous requirement text from section 5 and restore = to previous version. >>>>>>=20 >>>>>> Amend the text in section 6 from: >>>>>>=20 >>>>>> To >>>>>> simplify the subsequent description we assume in the PoP = architecture >>>>>> that the token itself is digitally signed by the authorization = server >>>>>> and therefore cannot be modified. >>>>>>=20 >>>>>>=20 >>>>>> To: >>>>>>=20 >>>>>> In all such cases, the token remains opaque to the client. To >>>>>> simplify the subsequent example and description we assume in = the PoP architecture >>>>>> that the token itself cannot be modified by the client, either = due to >>>>>> cryptographic protection (such as signature or encryption) or = use of=20 >>>>>> a reference value with sufficient entropy and associated = secure lookup. >>>>>> These are characteristics shared with bearer tokens and more = information >>>>>> on best practices can be found in [[RFC6819]] and in the = security=20 >>>>>> considerations section of [[RFC6750]].=20 >>>>>>=20 >>>>>>=20 >>>>>> =E2=80=94 Justin >>>>>>=20 >>>>>>> On Nov 25, 2015, at 3:39 PM, Kathleen Moriarty = > wrote: >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> Sent from my iPhone >>>>>>>=20 >>>>>>> On Nov 25, 2015, at 3:20 PM, John Bradley > wrote: >>>>>>>=20 >>>>>>>> Tokens are signed or the information is otherwise integrity = protected between the AS and the RS. =20 >>>>>>>>=20 >>>>>>>> I suspect Kathleen is concerned about the key getting modified = in transit. =20 >>>>>>>> That needs to be protected against, but there is more than one = way to do that. >>>>>>>=20 >>>>>>> Phil is correct. I was looking for consistency between the = sections since they related to each other. If there is a security risk = or consideration, that needs to be explicitly called out as a concern = such as a key being modified in transit. If there are options to = protect against that, those would ideally be required or would have = warnings. >>>>>>>>=20 >>>>>>>> So sending the public key in a unsigned JWT access token would = be immensely stupid, not just for PoP but for scopes and everything = else. >>>>>>>=20 >>>>>>> Good, easy to require then. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Kathleen=20 >>>>>>>>=20 >>>>>>>> In OAuth 2 all tokens need to be integrity protected between = the AS and RS. =20 >>>>>>>> That can be via signature, by having a reference with = sufficient entropy and secure introspection or database lookup. >>>>>>>>=20 >>>>>>>> I think that is a OAuth 2 security consideration. We are = adding a additional confirmation claim to the existing information that = needs to be protected the same as the rest. >>>>>>>>=20 >>>>>>>> John B. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Nov 25, 2015, at 4:38 PM, Phil Hunt > wrote: >>>>>>>>>=20 >>>>>>>>> >>>>>>>>> If there is agreement that tokens are opaque then the = requirement that tokens be signed must be removed from the threat = mitigation requirements.=20 >>>>>>>>>=20 >>>>>>>>> And the paragraph in sec 5 that brian was concerned about be = restored.=20 >>>>>>>>>=20 >>>>>>>>> Phil >>>>>>>>>=20 >>>>>>>>> On Nov 25, 2015, at 11:24, Justin Richer > wrote: >>>>>>>>>=20 >>>>>>>>>> It is still end to end authentication with opaque tokens =E2=80= =94 since all OAuth tokens, including PoP tokens, have always been = intended to be opaque to the client. That hasn=E2=80=99t changed and = that isn=E2=80=99t the intent of this document. If that=E2=80=99s how = people are reading it then we need to pull it back and rewrite it so = that=E2=80=99s not the case. >>>>>>>>>>=20 >>>>>>>>>> The client gets a token that has two parts: the token and the = key. The token is analogous to the access_token we have today and would = come out of the server in the same field. The key is handed to the = client alongside the token or registered by the client during the token = request. Either way there=E2=80=99s an association between the two but = it=E2=80=99s not the same association as a public/private keypair.=20 >>>>>>>>>>=20 >>>>>>>>>> It=E2=80=99s possible to sign the token itself, but the = client doesn=E2=80=99t care. It sends the token and signs the HTTP = request to the RS whether the token is signed, unsigned, hex blob, = encrypted, or anything else. The same series of options are available as = with bearer tokens. PoP tokens have never, ever been intended to be = anything but opaque to the client. >>>>>>>>>>=20 >>>>>>>>>> The token can=E2=80=99t be opaque to the RS, which has to = figure out what key to use to check the message signature. But we=E2=80=99= ve got options there, like the embedded key in a JWT from Mike=E2=80=99s = draft, or doing introspection to get the key (from an extension that = hasn=E2=80=99t been written yet), or simply looking it up in the same = database because the RS and the AS are in the same box. Does this = structure/service/database choice sound familiar? It should, it=E2=80=99s = the same as bearer tokens. This is also how the RS gets information like = which scopes are associated with the token, if it=E2=80=99s expired, and = all that.=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> So here=E2=80=99s how I see it going on the wire: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> (I just wrote this up so there are probably holes. Here=E2=80=99= s the source if anyone wants to tweak it: = http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW50IGFzIEMKA= AwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3R= lY3RlZABICmFzIFJTCgoKClJPLS0 = -QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmV= jdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAK= QcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADA= FKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIA= E8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmN= sdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduY= XR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwB= iBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZ= CkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4= OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&= s=3Dmodern-blue ) >>>>>>>>>>=20 >>>>>>>>>> The client is oblivious to the token just like always. This = is intentional. The RS has the same options to figure out how to process = the token. >>>>>>>>>>=20 >>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>=20 >>>>>>>>>>> On Nov 25, 2015, at 2:03 PM, Phil Hunt > wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Folks,=20 >>>>>>>>>>>=20 >>>>>>>>>>> >>>>>>>>>>> I did not want to go here either. :-) >>>>>>>>>>>=20 >>>>>>>>>>> I don=E2=80=99t read sec 6 as examples. I believe this may = stem from the pop-architecture documents having a dual role as both = =E2=80=9Carchitecture=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D. Maybe we = should clarify the purpose of the document? >>>>>>>>>>>=20 >>>>>>>>>>> I believe section 6 is talking about threat mitigation = assumptions based on the examples that need to be implemented. I am = assuming these are requirements that the other specifications SHOULD = implement. >>>>>>>>>>>=20 >>>>>>>>>>> >>>>>>>>>>> I do not believe we have discussed Opaque PoP tokens and any = inherent risks because the client is not or is unable to validate the = authenticity of the token. Does this introduce the possibility of a = MITM attack where a client can be convinced to sign requests for an = attacker? >>>>>>>>>>>=20 >>>>>>>>>>> If we want to include opaque PoP, I think we need to take a = pause and consider / discuss any threats here. >>>>>>>>>>>=20 >>>>>>>>>>> I find the desire for opaque PoP tokens to be a bit = contradictory. If we=E2=80=99re saying we don=E2=80=99t want to trust = TLS alone (e.g. because of load-balancer termination), why would we then = say, but we are perfectly willing to accept it worked for the OAuth AS = exchanges? Maybe I was very wrong here, but my assumption all along is = that for PoP we=E2=80=99re talking about end-to-end authentication of = all parties except in the case of 3.3 where we simply want to protect an = access token over a non-TLS HTTP connection. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Phil >>>>>>>>>>>=20 >>>>>>>>>>> @independentid >>>>>>>>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>>>>>>>> On Nov 25, 2015, at 10:48 AM, Brian Campbell = > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> While I can't say I disagree with the deeper existential = questions about the draft that Justin raises, I was trying not to go = there and rather just point out concerns with the newly added text.=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> The text Phil cites from Sec 6 doesn't say the client must = be able to parse and verify the token. It's an assumption to simplify = the examples that follow and still the token is opaque to the client. I = reread the whole draft (reluctantly) and there's nothing that says the = token has to be non-opaque to the client. And it does talk about = reference style tokens and encrypted tokens, both of which rely on the = opaqueness to the client.=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer = > wrote: >>>>>>>>>>>> Right, I read that as text for describing the examples and = not for describing requirements. >>>>>>>>>>>>=20 >>>>>>>>>>>> The token itself doesn=E2=80=99t have to be signed at all. >>>>>>>>>>>>=20 >>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>=20 >>>>>>>>>>>>> On Nov 25, 2015, at 1:05 PM, Phil Hunt = > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Ok. Well this was requested by Kathleen because of this = paragraph in Sec 6.=E2=80=A6 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> To simplify the subsequent description we assume in the = PoP architecture >>>>>>>>>>>>> that the token itself is digitally signed by the = authorization server >>>>>>>>>>>>> and therefore cannot be modified. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Please=20 >>>>>>>>>>>>> Phil >>>>>>>>>>>>>=20 >>>>>>>>>>>>> @independentid >>>>>>>>>>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>>>>>>>>>> On Nov 25, 2015, at 9:33 AM, Justin Richer = > wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The token doesn=E2=80=99t have to be signed and the = client doesn=E2=80=99t have to verify the signature on the token. = That=E2=80=99s not PoP. The request has to be signed in a way that = includes the token. The token itself can still be opaque. The *key* = material can=E2=80=99t be opaque to the client, but the *token* material = still is. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I agree with Brian that this statement is misleading. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The examples use a signed token but that is absolutely = not a requirement. Maybe the examples shouldn=E2=80=99t all use one = style. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> What=E2=80=99s most difficult about this particular spec = is that it=E2=80=99s very hand-wavy, saying =E2=80=9Cthis is kinda a = thing that kinda works like this=E2=80=9D without saying how to actually = do it. I=E2=80=99m honestly not sure it=E2=80=99s worth publishing as an = RFC in its own right but I=E2=80=99m not going to stand in its way. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Nov 25, 2015, at 12:14 PM, Brian Campbell = > wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Where does it say that?=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt = > wrote: >>>>>>>>>>>>>>> Except that later on we require the token be signed and = the client verify that signed token. IOW mutual pop.=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Phil >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Nov 25, 2015, at 07:30, Brian Campbell = > wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Looking at the diff I noticed the following new text, = which seems to conflate bearer/PoP and opaqueness to the client. A = client demonstrating proof-of-possession of some key is orthogonal to = the client being able to parse and understand the access token itself.=20= >>>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>>> "In contrast to bearer tokens [RFC6750] which call for = tokens that are opaque to OAuth 2.0 clients, this specification defines = the requirements for proof-of-possession ("PoP") tokens that may be = parsed and verified by OAuth 2.0 clients and relying parties." >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt = > wrote: >>>>>>>>>>>>>>>> This draft addresses review comments from Kathleen and = Erik raised since the last draft. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> It may not include some of the discussion from = yesterday/today. I will add that as the group decides. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Phil >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> @independentid >>>>>>>>>>>>>>>> www.independentid.com >>>>>>>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> > On Nov 24, 2015, at 12:05 PM, = internet-drafts@ietf.org wrote: >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>>>>>>>>>>> > This draft is a work item of the Web Authorization = Protocol Working Group of the IETF. >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > Title : OAuth 2.0 = Proof-of-Possession (PoP) Security Architecture >>>>>>>>>>>>>>>> > Authors : Phil Hunt >>>>>>>>>>>>>>>> > Justin Richer >>>>>>>>>>>>>>>> > William Mills >>>>>>>>>>>>>>>> > Prateek Mishra >>>>>>>>>>>>>>>> > Hannes Tschofenig >>>>>>>>>>>>>>>> > Filename : = draft-ietf-oauth-pop-architecture-06.txt >>>>>>>>>>>>>>>> > Pages : 23 >>>>>>>>>>>>>>>> > Date : 2015-11-24 >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > 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 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. >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > The IETF datatracker status page for this draft is: >>>>>>>>>>>>>>>> > = https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ = >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > There's also a htmlized version available at: >>>>>>>>>>>>>>>> > = https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 = >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > A diff from the previous version is available at: >>>>>>>>>>>>>>>> > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 = = >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > 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 . >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > Internet-Drafts are also available by anonymous FTP = at: >>>>>>>>>>>>>>>> > ftp://ftp.ietf.org/internet-drafts/ = >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>>>>>> > OAuth mailing list >>>>>>>>>>>>>>>> > OAuth@ietf.org >>>>>>>>>>>>>>>> > https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>>>> =09= >>>>>>>>>>>>>>>> Brian Campbell >>>>>>>>>>>>>>>> Distinguished Engineer >>>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>>>>>>> @pingidentity >>>>>>>>>>>>>>>> Connect with us! >>>>>>>>>>>>>>>> = >>>>>>>>>>>>>>>> = = = = = = = = = >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>>> =09= >>>>>>>>>>>>>>> Brian Campbell >>>>>>>>>>>>>>> Distinguished Engineer >>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>>>>>> @pingidentity >>>>>>>>>>>>>>> Connect with us! >>>>>>>>>>>>>>> = >>>>>>>>>>>>>>> = = = = = = = = = _____________________________________= __________ >>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> --=20 >>>>>>>>>>>> =09 >>>>>>>>>>>> Brian Campbell >>>>>>>>>>>> Distinguished Engineer >>>>>>>>>>>> Ping Identity >>>>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>>> @pingidentity >>>>>>>>>>>> Connect with us! >>>>>>>>>>>> = >>>>>>>>>>>> = = = = = = = = >>>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>>=20 >>>>> Best regards, >>>>> Kathleen >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>>=20 >>> Best regards, >>> Kathleen >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_7DFD03CA-0DF7-4D71-93A7-C502C5B95887 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 You=E2=80=99ve got =E2=80=9CThe token remains opaque to the = client=E2=80=9D in there twice now. I had cut out the middle part the = first sentence in the second paragraph below, but that was hard to = highlight. If you take my text as-is that=E2=80=99s what I meant for the = edited form.

Thanks
 =E2=80=94 Justin

On Dec 1, 2015, at 2:18 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Including = Justin=E2=80=99s revision:

  A large range of threats can be mitigated by protecting the =
content
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).

   To simplify discussion in the following examples, we assume that the
   token itself is integrity protected by the authorization server and
   the token remains opaque to the client.  The token itself cannot be
   modified by the client, either due to cryptographic protection (such
   as signature or encryption) or the use of a reference value with
   sufficient entropy and associated secure lookup.  The token remains
   opaque to the client.  These are characteristics shared with bearer
   tokens and more information on best practices can be found in
   [RFC6819] and in the security considerations section of [RFC6750].


On Dec 1, 2015, at 10:35 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Thanks Justin. Your = tweaks look good to me.


On Dec 1, 2015, at 10:28 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

The changes work for me, thanks.

On Tue, = Dec 1, 2015 at 1:27 PM, Justin Richer <jricher@mit.edu> wrote:
That=E2=80=99s much better. I would also suggest that a few = edits to hammer home that this is an example

 A large range of threats can =
be mitigated by protecting the content
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).  To
   simplify discussion=
 in the following example we assume=20
   that the token itself [=E2=80=A6]
   cannot be modified by the client, either due to cryptographic
   protection (such as signature or encryption) or use of a reference
   value with sufficient entropy and associated secure lookup.  =
The token remains =
opaque to the client.
These
   are characteristics shared with bearer tokens and more information on
   best practices can be found in [RFC6819] and in the security
   considerations section of =
[RFC6750].

That=E2=80=99s really what=E2=80=99s going on by my read. = Thoughts?

 =E2=80= =94 Justin

On Dec 1, 2015, at 1:08 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

I=E2=80=99ve reviewed the = comments from John, Justin and Kathleen. As suggested, I plan to remove = the erroneous first paragraph in section 5 (draft 06).

Combining the comments from this thread = about sec 6, here is the proposed new first paragraph:

 A large =
range of threats can be mitigated by protecting the content
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).  To
   simplify the subsequent description we assume in the PoP architecture
   that the token itself is integrity protected by the authorization
   server and the token remains opaque to the client.  The token itself
   cannot be modified by the client, either due to cryptographic
   protection (such as signature or encryption) or use of a reference
   value with sufficient entropy and associated secure lookup.  These
   are characteristics shared with bearer tokens and more information on
   best practices can be found in [RFC6819] and in the security
   considerations section of [RFC6750].
If this = looks good to the group, I=E2=80=99ll post draft 7 this afternoon = (pacific).

Thanks,


On Nov 25, 2015, at 2:19 PM, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> wrote:



On Wed, = Nov 25, 2015 at 3:58 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I am fine with that, however = saying integrity protected, may be better than signed.  May people = will argue that HMAC or encryption with sender verification is not = signature.

Good point, I also prefer integrity protected.  Are we = all good with this now?  I'd like to look at a diff to make sure = after following the thread.

Thanks!
Kathleen
 
However they are perfectly valid.


On Nov 25, 2015, at 5:53 PM, Justin Richer = <jricher@mit.edu> wrote:

The = requirement is not that signed JWTs be used, it=E2=80=99s that unsigned = JWTs not be used on their own. Reference tokens and encrypted JWTs are = also valid, as are other signed formats like SAML assertions or even a = COSE Token (if it=E2=80=99s encoded to HTTP friendliness). 

My = recommendation:

Remove the erroneous requirement text from section 5 and = restore to previous version.

Amend the text in section 6 = from:

   To
   simplify the subsequent description we assume in the PoP architecture

   that the token itself is digitally signed by =
the authorization server
   and therefore cannot be modified.


To:

   In all such cases, the token remains =
opaque to the client. To
   simplify the subsequent example and description we assume in the PoP =
architecture
   that the token itself cannot be =
modified by the client, either due to
   =
cryptographic protection (such as signature or encryption) or use =
of 
   a reference value with sufficient =
entropy and associated secure lookup.
   These are =
characteristics shared with bearer tokens and more information
   on best practices can be found in [[RFC6819]] and in the =
security 
   considerations section of =
[[RFC6750]].


 =E2=80=94 = Justin

On Nov 25, 2015, at 3:39 PM, = Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> = wrote:

Hi,

Sent from my iPhone

On = Nov 25, 2015, at 3:20 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Tokens are signed or the information is otherwise integrity = protected between the AS and the RS.  

I suspect Kathleen is concerned about = the key getting modified in transit.   
That needs to be protected against, but there is more than = one way to do that.

Phil is correct.  I was looking for consistency = between the sections since they related to each other.  If there is = a security risk or consideration, that needs to be explicitly called out = as a concern such as a key being modified in transit.  If there are = options to protect against that, those would ideally be required or = would have warnings.

So sending the public key in a unsigned JWT access token = would be immensely stupid,  not just for PoP but for scopes and = everything else.

Good, easy to require then.

Thanks,
Kathleen 

In OAuth 2 all tokens need to be integrity protected between = the AS and RS.  
That can be via signature, =  by having a reference with sufficient entropy and secure = introspection or database lookup.

I think that is a OAuth 2 security = consideration.   We are adding a additional confirmation claim to = the existing information that needs to be protected the same as the = rest.

John = B.


On Nov 25, 2015, at 4:38 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

<editors = hat>
If there is agreement that tokens are = opaque then the requirement that tokens be signed must be removed from = the threat mitigation requirements. 

And the paragraph in sec 5 that brian = was concerned about be restored. 

Phil

On Nov 25, 2015, at 11:24, Justin Richer <jricher@mit.edu> wrote:

It = is still end to end authentication with opaque tokens =E2=80=94 since = all OAuth tokens, including PoP tokens, have always been intended to be = opaque to the client. That hasn=E2=80=99t changed and that isn=E2=80=99t = the intent of this document. If that=E2=80=99s how people are reading it = then we need to pull it back and rewrite it so that=E2=80=99s not the = case.

The client = gets a token that has two parts: the token and the key. The token is = analogous to the access_token we have today and would come out of the = server in the same field. The key is handed to the client alongside the = token or registered by the client during the token request. Either way = there=E2=80=99s an association between the two but it=E2=80=99s not the = same association as a public/private keypair. 

It=E2=80=99s possible to = sign the token itself, but the client doesn=E2=80=99t care. It sends the = token and signs the HTTP request to the RS whether the token is signed, = unsigned, hex blob, encrypted, or anything else. The same series of = options are available as with bearer tokens. PoP tokens have never, ever = been intended to be anything but opaque to the client.

The token can=E2=80=99t = be opaque to the RS, which has to figure out what key to use to check = the message signature. But we=E2=80=99ve got options there, like the = embedded key in a JWT from Mike=E2=80=99s draft, or doing introspection = to get the key (from an extension that hasn=E2=80=99t been written yet), = or simply looking it up in the same database because the RS and the AS = are in the same box. Does this structure/service/database choice sound = familiar? It should, it=E2=80=99s the same as bearer tokens. This is = also how the RS gets information like which scopes are associated with = the token, if it=E2=80=99s expired, and all that. 




So here=E2=80=99s how I see it going on the wire:



3D"http://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DcGFydGljaXBhb=



(I just wrote this up so = there are probably holes. Here=E2=80=99s the source if anyone wants to = tweak it: http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW= 50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZB= UwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPl= JPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAV= BwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcm= VxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsA= EAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUz= ogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVj= awCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludH= Jvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGlj= IG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAI= QoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiBy= ZXR1cm4AhicJ&s=3Dmodern-blue )

The client is oblivious to the token = just like always. This is intentional. The RS has the same options to = figure out how to process the token.

 =E2=80=94 Justin

On Nov 25, 2015, at 2:03 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Folks, 

<editor = hat>
I did not want to go here either. = :-)

I don=E2=80=99= t read sec 6 as examples.  I believe this may stem from the = pop-architecture documents having a dual role as both =E2=80=9Carchitectur= e=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D.  Maybe we should clarify = the purpose of the document?

I believe section 6 is talking about = threat mitigation assumptions based on the examples that need to be = implemented.  I am assuming these are requirements that the other = specifications SHOULD implement.

<personal hat>
I do not believe we have discussed Opaque PoP tokens and any = inherent risks because the client is not or is unable to validate the = authenticity of the token.  Does this introduce the possibility of = a MITM attack where a client can be convinced to sign requests for an = attacker?

If = we want to include opaque PoP, I think we need to take a pause and = consider / discuss any threats here.

I find the desire for opaque PoP tokens = to be a bit contradictory. If we=E2=80=99re saying we don=E2=80=99t want = to trust TLS alone (e.g. because of load-balancer termination), why = would we then say, but we are perfectly willing to accept it worked for = the OAuth AS exchanges?  Maybe I was very wrong here, but my = assumption all along is that for PoP we=E2=80=99re talking about = end-to-end authentication of all parties except in the case of 3.3 where = we simply want to protect an access token over a non-TLS HTTP = connection.



On Nov 25, 2015, at 10:48 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

While I can't say I disagree with the deeper = existential questions about the draft that Justin raises, I was trying = not to go there and rather just point out concerns with the newly added = text.

The text Phil cites from Sec 6 = doesn't say the client must be able to parse and verify the token. It's = an assumption to simplify the examples that follow and still the token = is opaque to the client. I reread the whole draft (reluctantly) and = there's nothing that says the token has to be non-opaque to the client. = And it does talk about reference style tokens and encrypted tokens, both = of which rely on the opaqueness to the client.

On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer = <jricher@mit.edu> wrote:
Right, I read that as text for = describing the examples and not for describing requirements.

The token itself = doesn=E2=80=99t have to be signed at all.

 =E2=80=94 Justin

On Nov 25, 2015, at 1:05 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:

Ok. Well this was = requested by Kathleen because of this paragraph in Sec 6.=E2=80=A6

   =
To simplify the subsequent description we assume in the PoP =
architecture
   =
that the token itself is digitally signed by the authorization server

   and therefore cannot be modified.

Please 

On Nov 25, 2015, at 9:33 AM, Justin Richer <jricher@mit.edu> wrote:

The token = doesn=E2=80=99t have to be signed and the client doesn=E2=80=99t have to = verify the signature on the token. That=E2=80=99s not PoP. The request = has to be signed in a way that includes the token. The token itself can = still be opaque. The *key* material can=E2=80=99t be opaque to the = client, but the *token* material still is.

I agree with Brian that this statement = is misleading.

The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one = style.

What=E2=80= =99s most difficult about this particular spec is that it=E2=80=99s very = hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda works like = this=E2=80=9D without saying how to actually do it. I=E2=80=99m honestly = not sure it=E2=80=99s worth publishing as an RFC in its own right but = I=E2=80=99m not going to stand in its way.

 =E2=80=94 Justin

On Nov 25, 2015, at 12:14 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

Where does it say = that?



On Wed, = Nov 25, 2015 at 8:44 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Except that later on we require the token be = signed and the client verify that signed token. IOW mutual = pop. 

Phil

On Nov 25, 2015, at 07:30, = Brian Campbell <bcampbell@pingidentity.com> = wrote:

Looking at the = diff I noticed the following new text, which seems to conflate = bearer/PoP and opaqueness to the client. A client demonstrating = proof-of-possession of some key is orthogonal to the client being able = to parse and understand the access token itself.
 
"In contrast to bearer tokens [RFC6750] which call for tokens = that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
This draft = addresses review comments from Kathleen and Erik raised since the last = draft.

It may not include some of the discussion from yesterday/today.  I = will add that as the group decides.

Cheers,

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF.
>
>        Title          =  : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors        =  : Phil Hunt
>                  =         Justin Richer
>                  =         William Mills
>                  =         Prateek Mishra
>                  =         Hannes Tschofenig
>       Filename        : = draft-ietf-oauth-pop-architecture-06.txt
>       Pages          =  : 23
>       Date          =   : 2015-11-24
>
> 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 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.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth






--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


________________________________= _______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
________________________________= _______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





--

Best regards,
Kathleen
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--

Best regards,
Kathleen

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_7DFD03CA-0DF7-4D71-93A7-C502C5B95887-- From nobody Tue Dec 1 11:30:06 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B3F1B2A5E for ; Tue, 1 Dec 2015 11:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kw46NEB_jN-A for ; Tue, 1 Dec 2015 11:29:56 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E9B81B2F51 for ; Tue, 1 Dec 2015 11:29:56 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tB1JTrCR004518 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Dec 2015 19:29:54 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tB1JTrkD007326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Dec 2015 19:29:53 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tB1JTreP027853; Tue, 1 Dec 2015 19:29:53 GMT Received: from [10.0.1.22] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Dec 2015 11:29:51 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_6C26FE96-0A23-4CE1-A5BB-D289C12EF3A1" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Phil Hunt In-Reply-To: Date: Tue, 1 Dec 2015 11:29:49 -0800 Message-Id: <05F9B98F-18C5-404B-80FF-60328E736851@oracle.com> References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> <1AD1F44B-9837-4288-9997-5292F1DBE30E@oracle.com> <9E20E73C-AC35-4E03-A011-119A32CD0BF1@ve7jtb.com> <7431079B-818C-46E9-8102-D193E49384B2@gmail.com> <638FA321-4DE1-467C-9B5C-3BEA0EC3EB0F@mit.edu> <207E620F-97AA-4851-8776-2A7B1921D58A@ve7jtb.com> <8F038A71-! ! ! ! C047-42F6-9BA9-D697A14902E1@mit.edu> <9F9526D9-A32A-4E34-A54D-8CC47A15E862@oracle.com> <6636599A-B628-4ABE-88A9-911219501096@oracle.com> To: Justin Richer X-Mailer: Apple Mail (2.3096.5) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 19:30:04 -0000 --Apple-Mail=_6C26FE96-0A23-4CE1-A5BB-D289C12EF3A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Justin, I was wondering why you put in the second sentence in bold. :-) I=E2=80=99m not sure which one you want to take out. Would you post the = text exactly as you would like it? Thanks, Phil @independentid www.independentid.com phil.hunt@oracle.com > On Dec 1, 2015, at 11:21 AM, Justin Richer wrote: >=20 > You=E2=80=99ve got =E2=80=9CThe token remains opaque to the client=E2=80= =9D in there twice now. I had cut out the middle part the first sentence = in the second paragraph below, but that was hard to highlight. If you = take my text as-is that=E2=80=99s what I meant for the edited form. >=20 > Thanks > =E2=80=94 Justin >=20 >> On Dec 1, 2015, at 2:18 PM, Phil Hunt > wrote: >>=20 >> Including Justin=E2=80=99s revision: >>=20 >> A large range of threats can be mitigated by protecting the content >> of the token, for example using a digital signature or a keyed >> message digest. Alternatively, the content of the token could be >> passed by reference rather than by value (requiring a separate >> message exchange to resolve the reference to the token content). >>=20 >> To simplify discussion in the following examples, we assume that = the >> token itself is integrity protected by the authorization server = and >> the token remains opaque to the client. The token itself cannot = be >> modified by the client, either due to cryptographic protection = (such >> as signature or encryption) or the use of a reference value with >> sufficient entropy and associated secure lookup. The token = remains >> opaque to the client. These are characteristics shared with = bearer >> tokens and more information on best practices can be found in >> [RFC6819] and in the security considerations section of [RFC6750]. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com = phil.hunt@oracle.com = >>> On Dec 1, 2015, at 10:35 AM, Phil Hunt > wrote: >>>=20 >>> Thanks Justin. Your tweaks look good to me. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com = phil.hunt@oracle.com = >>>> On Dec 1, 2015, at 10:28 AM, Kathleen Moriarty = > wrote: >>>>=20 >>>> The changes work for me, thanks. >>>>=20 >>>> On Tue, Dec 1, 2015 at 1:27 PM, Justin Richer > wrote: >>>> That=E2=80=99s much better. I would also suggest that a few edits = to hammer home that this is an example >>>>=20 >>>>> A large range of threats can be mitigated by protecting the = content >>>>> of the token, for example using a digital signature or a keyed >>>>> message digest. Alternatively, the content of the token could = be >>>>> passed by reference rather than by value (requiring a separate >>>>> message exchange to resolve the reference to the token = content). To >>>>> simplify discussion in the following example we assume=20 >>>>> that the token itself [=E2=80=A6] >>>>> cannot be modified by the client, either due to cryptographic >>>>> protection (such as signature or encryption) or use of a = reference >>>>> value with sufficient entropy and associated secure lookup. = The token remains opaque to the client. >>>>> These >>>>> are characteristics shared with bearer tokens and more = information on >>>>> best practices can be found in [RFC6819] and in the security >>>>> considerations section of [RFC6750]. >>>>=20 >>>> That=E2=80=99s really what=E2=80=99s going on by my read. Thoughts? >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Dec 1, 2015, at 1:08 PM, Phil Hunt > wrote: >>>>>=20 >>>>> I=E2=80=99ve reviewed the comments from John, Justin and Kathleen. = As suggested, I plan to remove the erroneous first paragraph in section = 5 (draft 06). >>>>>=20 >>>>> Combining the comments from this thread about sec 6, here is the = proposed new first paragraph: >>>>>=20 >>>>> A large range of threats can be mitigated by protecting the = content >>>>> of the token, for example using a digital signature or a keyed >>>>> message digest. Alternatively, the content of the token could = be >>>>> passed by reference rather than by value (requiring a separate >>>>> message exchange to resolve the reference to the token = content). To >>>>> simplify the subsequent description we assume in the PoP = architecture >>>>> that the token itself is integrity protected by the = authorization >>>>> server and the token remains opaque to the client. The token = itself >>>>> cannot be modified by the client, either due to cryptographic >>>>> protection (such as signature or encryption) or use of a = reference >>>>> value with sufficient entropy and associated secure lookup. = These >>>>> are characteristics shared with bearer tokens and more = information on >>>>> best practices can be found in [RFC6819] and in the security >>>>> considerations section of [RFC6750]. >>>>> If this looks good to the group, I=E2=80=99ll post draft 7 this = afternoon (pacific). >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>> On Nov 25, 2015, at 2:19 PM, Kathleen Moriarty = > wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Wed, Nov 25, 2015 at 3:58 PM, John Bradley > wrote: >>>>>> I am fine with that, however saying integrity protected, may be = better than signed. May people will argue that HMAC or encryption with = sender verification is not signature. >>>>>>=20 >>>>>> Good point, I also prefer integrity protected. Are we all good = with this now? I'd like to look at a diff to make sure after following = the thread. >>>>>>=20 >>>>>> Thanks! >>>>>> Kathleen >>>>>>=20 >>>>>> =20 >>>>>> However they are perfectly valid. >>>>>>=20 >>>>>>=20 >>>>>>> On Nov 25, 2015, at 5:53 PM, Justin Richer > wrote: >>>>>>>=20 >>>>>>> The requirement is not that signed JWTs be used, it=E2=80=99s = that unsigned JWTs not be used on their own. Reference tokens and = encrypted JWTs are also valid, as are other signed formats like SAML = assertions or even a COSE Token (if it=E2=80=99s encoded to HTTP = friendliness).=20 >>>>>>>=20 >>>>>>> My recommendation: >>>>>>>=20 >>>>>>> Remove the erroneous requirement text from section 5 and restore = to previous version. >>>>>>>=20 >>>>>>> Amend the text in section 6 from: >>>>>>>=20 >>>>>>> To >>>>>>> simplify the subsequent description we assume in the PoP = architecture >>>>>>> that the token itself is digitally signed by the = authorization server >>>>>>> and therefore cannot be modified. >>>>>>>=20 >>>>>>>=20 >>>>>>> To: >>>>>>>=20 >>>>>>> In all such cases, the token remains opaque to the client. To >>>>>>> simplify the subsequent example and description we assume in = the PoP architecture >>>>>>> that the token itself cannot be modified by the client, = either due to >>>>>>> cryptographic protection (such as signature or encryption) or = use of=20 >>>>>>> a reference value with sufficient entropy and associated = secure lookup. >>>>>>> These are characteristics shared with bearer tokens and more = information >>>>>>> on best practices can be found in [[RFC6819]] and in the = security=20 >>>>>>> considerations section of [[RFC6750]].=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> =E2=80=94 Justin >>>>>>>=20 >>>>>>>> On Nov 25, 2015, at 3:39 PM, Kathleen Moriarty = > wrote: >>>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> Sent from my iPhone >>>>>>>>=20 >>>>>>>> On Nov 25, 2015, at 3:20 PM, John Bradley > wrote: >>>>>>>>=20 >>>>>>>>> Tokens are signed or the information is otherwise integrity = protected between the AS and the RS. =20 >>>>>>>>>=20 >>>>>>>>> I suspect Kathleen is concerned about the key getting modified = in transit. =20 >>>>>>>>> That needs to be protected against, but there is more than one = way to do that. >>>>>>>>=20 >>>>>>>> Phil is correct. I was looking for consistency between the = sections since they related to each other. If there is a security risk = or consideration, that needs to be explicitly called out as a concern = such as a key being modified in transit. If there are options to = protect against that, those would ideally be required or would have = warnings. >>>>>>>>>=20 >>>>>>>>> So sending the public key in a unsigned JWT access token would = be immensely stupid, not just for PoP but for scopes and everything = else. >>>>>>>>=20 >>>>>>>> Good, easy to require then. >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>> Kathleen=20 >>>>>>>>>=20 >>>>>>>>> In OAuth 2 all tokens need to be integrity protected between = the AS and RS. =20 >>>>>>>>> That can be via signature, by having a reference with = sufficient entropy and secure introspection or database lookup. >>>>>>>>>=20 >>>>>>>>> I think that is a OAuth 2 security consideration. We are = adding a additional confirmation claim to the existing information that = needs to be protected the same as the rest. >>>>>>>>>=20 >>>>>>>>> John B. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On Nov 25, 2015, at 4:38 PM, Phil Hunt > wrote: >>>>>>>>>>=20 >>>>>>>>>> >>>>>>>>>> If there is agreement that tokens are opaque then the = requirement that tokens be signed must be removed from the threat = mitigation requirements.=20 >>>>>>>>>>=20 >>>>>>>>>> And the paragraph in sec 5 that brian was concerned about be = restored.=20 >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>> On Nov 25, 2015, at 11:24, Justin Richer > wrote: >>>>>>>>>>=20 >>>>>>>>>>> It is still end to end authentication with opaque tokens =E2=80= =94 since all OAuth tokens, including PoP tokens, have always been = intended to be opaque to the client. That hasn=E2=80=99t changed and = that isn=E2=80=99t the intent of this document. If that=E2=80=99s how = people are reading it then we need to pull it back and rewrite it so = that=E2=80=99s not the case. >>>>>>>>>>>=20 >>>>>>>>>>> The client gets a token that has two parts: the token and = the key. The token is analogous to the access_token we have today and = would come out of the server in the same field. The key is handed to the = client alongside the token or registered by the client during the token = request. Either way there=E2=80=99s an association between the two but = it=E2=80=99s not the same association as a public/private keypair.=20 >>>>>>>>>>>=20 >>>>>>>>>>> It=E2=80=99s possible to sign the token itself, but the = client doesn=E2=80=99t care. It sends the token and signs the HTTP = request to the RS whether the token is signed, unsigned, hex blob, = encrypted, or anything else. The same series of options are available as = with bearer tokens. PoP tokens have never, ever been intended to be = anything but opaque to the client. >>>>>>>>>>>=20 >>>>>>>>>>> The token can=E2=80=99t be opaque to the RS, which has to = figure out what key to use to check the message signature. But we=E2=80=99= ve got options there, like the embedded key in a JWT from Mike=E2=80=99s = draft, or doing introspection to get the key (from an extension that = hasn=E2=80=99t been written yet), or simply looking it up in the same = database because the RS and the AS are in the same box. Does this = structure/service/database choice sound familiar? It should, it=E2=80=99s = the same as bearer tokens. This is also how the RS gets information like = which scopes are associated with the token, if it=E2=80=99s expired, and = all that.=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> So here=E2=80=99s how I see it going on the wire: >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> (I just wrote this up so there are probably holes. Here=E2=80=99= s the source if anyone wants to tweak it: = http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW50IGFzIEMKA= AwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3R= lY3RlZABICmFzIFJTCgoKClJPLS0 = -QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmV= jdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAK= QcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADA= FKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIA= E8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmN= sdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduY= XR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwB= iBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZ= CkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4= OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&= s=3Dmodern-blue ) >>>>>>>>>>>=20 >>>>>>>>>>> The client is oblivious to the token just like always. This = is intentional. The RS has the same options to figure out how to process = the token. >>>>>>>>>>>=20 >>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>=20 >>>>>>>>>>>> On Nov 25, 2015, at 2:03 PM, Phil Hunt = > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> Folks,=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> >>>>>>>>>>>> I did not want to go here either. :-) >>>>>>>>>>>>=20 >>>>>>>>>>>> I don=E2=80=99t read sec 6 as examples. I believe this may = stem from the pop-architecture documents having a dual role as both = =E2=80=9Carchitecture=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D. Maybe we = should clarify the purpose of the document? >>>>>>>>>>>>=20 >>>>>>>>>>>> I believe section 6 is talking about threat mitigation = assumptions based on the examples that need to be implemented. I am = assuming these are requirements that the other specifications SHOULD = implement. >>>>>>>>>>>>=20 >>>>>>>>>>>> >>>>>>>>>>>> I do not believe we have discussed Opaque PoP tokens and = any inherent risks because the client is not or is unable to validate = the authenticity of the token. Does this introduce the possibility of a = MITM attack where a client can be convinced to sign requests for an = attacker? >>>>>>>>>>>>=20 >>>>>>>>>>>> If we want to include opaque PoP, I think we need to take a = pause and consider / discuss any threats here. >>>>>>>>>>>>=20 >>>>>>>>>>>> I find the desire for opaque PoP tokens to be a bit = contradictory. If we=E2=80=99re saying we don=E2=80=99t want to trust = TLS alone (e.g. because of load-balancer termination), why would we then = say, but we are perfectly willing to accept it worked for the OAuth AS = exchanges? Maybe I was very wrong here, but my assumption all along is = that for PoP we=E2=80=99re talking about end-to-end authentication of = all parties except in the case of 3.3 where we simply want to protect an = access token over a non-TLS HTTP connection. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Phil >>>>>>>>>>>>=20 >>>>>>>>>>>> @independentid >>>>>>>>>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>>>>>>>>> On Nov 25, 2015, at 10:48 AM, Brian Campbell = > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> While I can't say I disagree with the deeper existential = questions about the draft that Justin raises, I was trying not to go = there and rather just point out concerns with the newly added text.=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The text Phil cites from Sec 6 doesn't say the client must = be able to parse and verify the token. It's an assumption to simplify = the examples that follow and still the token is opaque to the client. I = reread the whole draft (reluctantly) and there's nothing that says the = token has to be non-opaque to the client. And it does talk about = reference style tokens and encrypted tokens, both of which rely on the = opaqueness to the client.=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer = > wrote: >>>>>>>>>>>>> Right, I read that as text for describing the examples and = not for describing requirements. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The token itself doesn=E2=80=99t have to be signed at all. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Nov 25, 2015, at 1:05 PM, Phil Hunt = > wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Ok. Well this was requested by Kathleen because of this = paragraph in Sec 6.=E2=80=A6 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> To simplify the subsequent description we assume in = the PoP architecture >>>>>>>>>>>>>> that the token itself is digitally signed by the = authorization server >>>>>>>>>>>>>> and therefore cannot be modified. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Please=20 >>>>>>>>>>>>>> Phil >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> @independentid >>>>>>>>>>>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>>>>>>>>>>> On Nov 25, 2015, at 9:33 AM, Justin Richer = > wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The token doesn=E2=80=99t have to be signed and the = client doesn=E2=80=99t have to verify the signature on the token. = That=E2=80=99s not PoP. The request has to be signed in a way that = includes the token. The token itself can still be opaque. The *key* = material can=E2=80=99t be opaque to the client, but the *token* material = still is. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I agree with Brian that this statement is misleading. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The examples use a signed token but that is absolutely = not a requirement. Maybe the examples shouldn=E2=80=99t all use one = style. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> What=E2=80=99s most difficult about this particular spec = is that it=E2=80=99s very hand-wavy, saying =E2=80=9Cthis is kinda a = thing that kinda works like this=E2=80=9D without saying how to actually = do it. I=E2=80=99m honestly not sure it=E2=80=99s worth publishing as an = RFC in its own right but I=E2=80=99m not going to stand in its way. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Nov 25, 2015, at 12:14 PM, Brian Campbell = > wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Where does it say that?=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt = > wrote: >>>>>>>>>>>>>>>> Except that later on we require the token be signed and = the client verify that signed token. IOW mutual pop.=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Phil >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Nov 25, 2015, at 07:30, Brian Campbell = > wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Looking at the diff I noticed the following new text, = which seems to conflate bearer/PoP and opaqueness to the client. A = client demonstrating proof-of-possession of some key is orthogonal to = the client being able to parse and understand the access token itself.=20= >>>>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>>>> "In contrast to bearer tokens [RFC6750] which call for = tokens that are opaque to OAuth 2.0 clients, this specification defines = the requirements for proof-of-possession ("PoP") tokens that may be = parsed and verified by OAuth 2.0 clients and relying parties." >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt = > wrote: >>>>>>>>>>>>>>>>> This draft addresses review comments from Kathleen and = Erik raised since the last draft. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> It may not include some of the discussion from = yesterday/today. I will add that as the group decides. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Phil >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> @independentid >>>>>>>>>>>>>>>>> www.independentid.com >>>>>>>>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> > On Nov 24, 2015, at 12:05 PM, = internet-drafts@ietf.org wrote: >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>>>>>>>>>>>> > This draft is a work item of the Web Authorization = Protocol Working Group of the IETF. >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > Title : OAuth 2.0 = Proof-of-Possession (PoP) Security Architecture >>>>>>>>>>>>>>>>> > Authors : Phil Hunt >>>>>>>>>>>>>>>>> > Justin Richer >>>>>>>>>>>>>>>>> > William Mills >>>>>>>>>>>>>>>>> > Prateek Mishra >>>>>>>>>>>>>>>>> > Hannes Tschofenig >>>>>>>>>>>>>>>>> > Filename : = draft-ietf-oauth-pop-architecture-06.txt >>>>>>>>>>>>>>>>> > Pages : 23 >>>>>>>>>>>>>>>>> > Date : 2015-11-24 >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > 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 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. >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > The IETF datatracker status page for this draft is: >>>>>>>>>>>>>>>>> > = https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ = >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > There's also a htmlized version available at: >>>>>>>>>>>>>>>>> > = https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 = >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > A diff from the previous version is available at: >>>>>>>>>>>>>>>>> > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 = = >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > 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 . >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > Internet-Drafts are also available by anonymous FTP = at: >>>>>>>>>>>>>>>>> > ftp://ftp.ietf.org/internet-drafts/ = >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>>>>>>> > OAuth mailing list >>>>>>>>>>>>>>>>> > OAuth@ietf.org >>>>>>>>>>>>>>>>> > https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>>>>> =09= >>>>>>>>>>>>>>>>> Brian Campbell >>>>>>>>>>>>>>>>> Distinguished Engineer >>>>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>>>>>>>> @pingidentity >>>>>>>>>>>>>>>>> Connect with us! >>>>>>>>>>>>>>>>> = >>>>>>>>>>>>>>>>> = = = = = = = = = >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>>>> =09= >>>>>>>>>>>>>>>> Brian Campbell >>>>>>>>>>>>>>>> Distinguished Engineer >>>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>>>>>>> @pingidentity >>>>>>>>>>>>>>>> Connect with us! >>>>>>>>>>>>>>>> = >>>>>>>>>>>>>>>> = = = = = = = = = _____________________________________= __________ >>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> --=20 >>>>>>>>>>>>> =09 >>>>>>>>>>>>> Brian Campbell >>>>>>>>>>>>> Distinguished Engineer >>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>>>> @pingidentity >>>>>>>>>>>>> Connect with us! >>>>>>>>>>>>> = >>>>>>>>>>>>> = = = = = = = = = >>>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>>=20 >>>>>> Best regards, >>>>>> Kathleen >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>>=20 >>>> Best regards, >>>> Kathleen >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_6C26FE96-0A23-4CE1-A5BB-D289C12EF3A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Justin,

I = was wondering why you put in the second sentence in bold. :-)

I=E2=80=99m not sure = which one you want to take out. Would you post the text exactly as you = would like it?

Thanks,


On Dec 1, 2015, at 11:21 AM, Justin Richer <jricher@mit.edu> = wrote:

You=E2=80=99ve = got =E2=80=9CThe token remains opaque to the client=E2=80=9D in there = twice now. I had cut out the middle part the first sentence in the = second paragraph below, but that was hard to highlight. If you take my = text as-is that=E2=80=99s what I meant for the edited form.

Thanks
 =E2=80=94 Justin

On Dec = 1, 2015, at 2:18 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Including = Justin=E2=80=99s revision:

  A large range of threats can be mitigated by protecting the =
content
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).

   To simplify discussion in the following examples, we assume that the
   token itself is integrity protected by the authorization server and
   the token remains opaque to the client.  The token itself cannot be
   modified by the client, either due to cryptographic protection (such
   as signature or encryption) or the use of a reference value with
   sufficient entropy and associated secure lookup.  The token remains
   opaque to the client.  These are characteristics shared with bearer
   tokens and more information on best practices can be found in
   [RFC6819] and in the security considerations section of [RFC6750].


On Dec 1, 2015, at 10:35 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Thanks Justin. Your = tweaks look good to me.


On Dec 1, 2015, at 10:28 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

The changes work for me, thanks.

On Tue, = Dec 1, 2015 at 1:27 PM, Justin Richer <jricher@mit.edu> wrote:
That=E2=80=99s much better. I would also suggest that a few = edits to hammer home that this is an example

 A large range of threats can =
be mitigated by protecting the content
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).  To
   simplify discussion=
 in the following example we assume=20
   that the token itself [=E2=80=A6]
   cannot be modified by the client, either due to cryptographic
   protection (such as signature or encryption) or use of a reference
   value with sufficient entropy and associated secure lookup.  =
The token remains =
opaque to the client.
These
   are characteristics shared with bearer tokens and more information on
   best practices can be found in [RFC6819] and in the security
   considerations section of =
[RFC6750].

That=E2=80=99s really what=E2=80=99s going on by my read. = Thoughts?

 =E2=80= =94 Justin

On Dec 1, 2015, at 1:08 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

I=E2=80=99ve reviewed the = comments from John, Justin and Kathleen. As suggested, I plan to remove = the erroneous first paragraph in section 5 (draft 06).

Combining the comments from this thread = about sec 6, here is the proposed new first paragraph:

 A large =
range of threats can be mitigated by protecting the content
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).  To
   simplify the subsequent description we assume in the PoP architecture
   that the token itself is integrity protected by the authorization
   server and the token remains opaque to the client.  The token itself
   cannot be modified by the client, either due to cryptographic
   protection (such as signature or encryption) or use of a reference
   value with sufficient entropy and associated secure lookup.  These
   are characteristics shared with bearer tokens and more information on
   best practices can be found in [RFC6819] and in the security
   considerations section of [RFC6750].
If this = looks good to the group, I=E2=80=99ll post draft 7 this afternoon = (pacific).

Thanks,


On Nov 25, 2015, at 2:19 PM, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> wrote:



On Wed, = Nov 25, 2015 at 3:58 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I am fine with that, however = saying integrity protected, may be better than signed.  May people = will argue that HMAC or encryption with sender verification is not = signature.

Good point, I also prefer integrity protected.  Are we = all good with this now?  I'd like to look at a diff to make sure = after following the thread.

Thanks!
Kathleen
 
However they are perfectly valid.


On Nov 25, 2015, at 5:53 PM, Justin Richer = <jricher@mit.edu> wrote:

The = requirement is not that signed JWTs be used, it=E2=80=99s that unsigned = JWTs not be used on their own. Reference tokens and encrypted JWTs are = also valid, as are other signed formats like SAML assertions or even a = COSE Token (if it=E2=80=99s encoded to HTTP friendliness). 

My = recommendation:

Remove the erroneous requirement text from section 5 and = restore to previous version.

Amend the text in section 6 = from:

   To
   simplify the subsequent description we assume in the PoP architecture

   that the token itself is digitally signed by =
the authorization server
   and therefore cannot be modified.


To:

   In all such cases, the token remains =
opaque to the client. To
   simplify the subsequent example and description we assume in the PoP =
architecture
   that the token itself cannot be =
modified by the client, either due to
   =
cryptographic protection (such as signature or encryption) or use =
of 
   a reference value with sufficient =
entropy and associated secure lookup.
   These are =
characteristics shared with bearer tokens and more information
   on best practices can be found in [[RFC6819]] and in the =
security 
   considerations section of =
[[RFC6750]].


 =E2=80=94 = Justin

On Nov 25, 2015, at 3:39 PM, = Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> = wrote:

Hi,

Sent from my iPhone

On = Nov 25, 2015, at 3:20 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Tokens are signed or the information is otherwise integrity = protected between the AS and the RS.  

I suspect Kathleen is concerned about = the key getting modified in transit.   
That needs to be protected against, but there is more than = one way to do that.

Phil is correct.  I was looking for consistency = between the sections since they related to each other.  If there is = a security risk or consideration, that needs to be explicitly called out = as a concern such as a key being modified in transit.  If there are = options to protect against that, those would ideally be required or = would have warnings.

So sending the public key in a unsigned JWT access token = would be immensely stupid,  not just for PoP but for scopes and = everything else.

Good, easy to require then.

Thanks,
Kathleen 

In OAuth 2 all tokens need to be integrity protected between = the AS and RS.  
That can be via signature, =  by having a reference with sufficient entropy and secure = introspection or database lookup.

I think that is a OAuth 2 security = consideration.   We are adding a additional confirmation claim to = the existing information that needs to be protected the same as the = rest.

John = B.


On Nov 25, 2015, at 4:38 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

<editors = hat>
If there is agreement that tokens are = opaque then the requirement that tokens be signed must be removed from = the threat mitigation requirements. 

And the paragraph in sec 5 that brian = was concerned about be restored. 

Phil

On Nov 25, 2015, at 11:24, Justin Richer <jricher@mit.edu> wrote:

It = is still end to end authentication with opaque tokens =E2=80=94 since = all OAuth tokens, including PoP tokens, have always been intended to be = opaque to the client. That hasn=E2=80=99t changed and that isn=E2=80=99t = the intent of this document. If that=E2=80=99s how people are reading it = then we need to pull it back and rewrite it so that=E2=80=99s not the = case.

The client = gets a token that has two parts: the token and the key. The token is = analogous to the access_token we have today and would come out of the = server in the same field. The key is handed to the client alongside the = token or registered by the client during the token request. Either way = there=E2=80=99s an association between the two but it=E2=80=99s not the = same association as a public/private keypair. 

It=E2=80=99s possible to = sign the token itself, but the client doesn=E2=80=99t care. It sends the = token and signs the HTTP request to the RS whether the token is signed, = unsigned, hex blob, encrypted, or anything else. The same series of = options are available as with bearer tokens. PoP tokens have never, ever = been intended to be anything but opaque to the client.

The token can=E2=80=99t = be opaque to the RS, which has to figure out what key to use to check = the message signature. But we=E2=80=99ve got options there, like the = embedded key in a JWT from Mike=E2=80=99s draft, or doing introspection = to get the key (from an extension that hasn=E2=80=99t been written yet), = or simply looking it up in the same database because the RS and the AS = are in the same box. Does this structure/service/database choice sound = familiar? It should, it=E2=80=99s the same as bearer tokens. This is = also how the RS gets information like which scopes are associated with = the token, if it=E2=80=99s expired, and all that. 




So here=E2=80=99s how I see it going on the wire:



3D"http://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DcGFydGljaXBhb=



(I just wrote this up so = there are probably holes. Here=E2=80=99s the source if anyone wants to = tweak it: http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW= 50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZB= UwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPl= JPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAV= BwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcm= VxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsA= EAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUz= ogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVj= awCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludH= Jvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGlj= IG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAI= QoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiBy= ZXR1cm4AhicJ&s=3Dmodern-blue )

The client is oblivious to the token = just like always. This is intentional. The RS has the same options to = figure out how to process the token.

 =E2=80=94 Justin

On Nov 25, 2015, at 2:03 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Folks, 

<editor = hat>
I did not want to go here either. = :-)

I don=E2=80=99= t read sec 6 as examples.  I believe this may stem from the = pop-architecture documents having a dual role as both =E2=80=9Carchitectur= e=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D.  Maybe we should clarify = the purpose of the document?

I believe section 6 is talking about = threat mitigation assumptions based on the examples that need to be = implemented.  I am assuming these are requirements that the other = specifications SHOULD implement.

<personal hat>
I do not believe we have discussed Opaque PoP tokens and any = inherent risks because the client is not or is unable to validate the = authenticity of the token.  Does this introduce the possibility of = a MITM attack where a client can be convinced to sign requests for an = attacker?

If = we want to include opaque PoP, I think we need to take a pause and = consider / discuss any threats here.

I find the desire for opaque PoP tokens = to be a bit contradictory. If we=E2=80=99re saying we don=E2=80=99t want = to trust TLS alone (e.g. because of load-balancer termination), why = would we then say, but we are perfectly willing to accept it worked for = the OAuth AS exchanges?  Maybe I was very wrong here, but my = assumption all along is that for PoP we=E2=80=99re talking about = end-to-end authentication of all parties except in the case of 3.3 where = we simply want to protect an access token over a non-TLS HTTP = connection.



On Nov 25, 2015, at 10:48 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

While I can't say I disagree with the deeper = existential questions about the draft that Justin raises, I was trying = not to go there and rather just point out concerns with the newly added = text.

The text Phil cites from Sec 6 = doesn't say the client must be able to parse and verify the token. It's = an assumption to simplify the examples that follow and still the token = is opaque to the client. I reread the whole draft (reluctantly) and = there's nothing that says the token has to be non-opaque to the client. = And it does talk about reference style tokens and encrypted tokens, both = of which rely on the opaqueness to the client.

On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer = <jricher@mit.edu> wrote:
Right, I read that as text for = describing the examples and not for describing requirements.

The token itself = doesn=E2=80=99t have to be signed at all.

 =E2=80=94 Justin

On Nov 25, 2015, at 1:05 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:

Ok. Well this was = requested by Kathleen because of this paragraph in Sec 6.=E2=80=A6

   =
To simplify the subsequent description we assume in the PoP =
architecture
   =
that the token itself is digitally signed by the authorization server

   and therefore cannot be modified.

Please 

On Nov 25, 2015, at 9:33 AM, Justin Richer <jricher@mit.edu> wrote:

The token = doesn=E2=80=99t have to be signed and the client doesn=E2=80=99t have to = verify the signature on the token. That=E2=80=99s not PoP. The request = has to be signed in a way that includes the token. The token itself can = still be opaque. The *key* material can=E2=80=99t be opaque to the = client, but the *token* material still is.

I agree with Brian that this statement = is misleading.

The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one = style.

What=E2=80= =99s most difficult about this particular spec is that it=E2=80=99s very = hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda works like = this=E2=80=9D without saying how to actually do it. I=E2=80=99m honestly = not sure it=E2=80=99s worth publishing as an RFC in its own right but = I=E2=80=99m not going to stand in its way.

 =E2=80=94 Justin

On Nov 25, 2015, at 12:14 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

Where does it say = that?



On Wed, = Nov 25, 2015 at 8:44 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Except that later on we require the token be = signed and the client verify that signed token. IOW mutual = pop. 

Phil

On Nov 25, 2015, at 07:30, = Brian Campbell <bcampbell@pingidentity.com> = wrote:

Looking at the = diff I noticed the following new text, which seems to conflate = bearer/PoP and opaqueness to the client. A client demonstrating = proof-of-possession of some key is orthogonal to the client being able = to parse and understand the access token itself.
 
"In contrast to bearer tokens [RFC6750] which call for tokens = that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
This draft = addresses review comments from Kathleen and Erik raised since the last = draft.

It may not include some of the discussion from yesterday/today.  I = will add that as the group decides.

Cheers,

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF.
>
>        Title          =  : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors        =  : Phil Hunt
>                  =         Justin Richer
>                  =         William Mills
>                  =         Prateek Mishra
>                  =         Hannes Tschofenig
>       Filename        : = draft-ietf-oauth-pop-architecture-06.txt
>       Pages          =  : 23
>       Date          =   : 2015-11-24
>
> 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 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.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth






--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


________________________________= _______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
________________________________= _______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





--

Best regards,
Kathleen
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--

Best regards,
Kathleen

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


= --Apple-Mail=_6C26FE96-0A23-4CE1-A5BB-D289C12EF3A1-- From nobody Tue Dec 1 11:33:00 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36191B2F57 for ; Tue, 1 Dec 2015 11:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0RgbNugdBbA for ; Tue, 1 Dec 2015 11:32:50 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1A11A1A54 for ; Tue, 1 Dec 2015 11:32:49 -0800 (PST) X-AuditID: 12074425-f793c6d000006975-21-565df5df2481 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id CF.C4.26997.FD5FD565; Tue, 1 Dec 2015 14:32:47 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id tB1JWkv0007660; Tue, 1 Dec 2015 14:32:46 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tB1JWhG6008417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Dec 2015 14:32:45 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_4C323F63-FBBB-4B84-A9BF-44B98B3C8DD5" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: <05F9B98F-18C5-404B-80FF-60328E736851@oracle.com> Date: Tue, 1 Dec 2015 14:32:43 -0500 Message-Id: <0FDEA284-A132-4AFB-808B-E691E9BB69CB@mit.edu> References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> <1AD1F44B-9837-4288-9997-5292F1DBE30E@oracle.com> <9E20E73C-AC35-4E03-A011-119A32CD0BF1@ve7jtb.com> <7431079B-818C-46E9-8102-D193E49384B2@gmail.com> <638FA321-4DE1-467C-9B5C-3BEA0EC3EB0F@mit.edu> <207E620F-97AA-4851-8776-2A7B1921D58A@ve7jtb.com> <8F038A71-! ! ! ! C 047-42F6-9BA9-D697A14902E1@mit.edu> <9F9526D9-A32A-4E34-A54D-8CC47A15E862@oracle.com> <6636599A-B628-4ABE-88A9-911219501096@oracle.com> <05F9B98F-18C5-404B-80FF-60328E736851@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUixCmqrXv/a2yYwdc+YYuGnfkWJ9++YrNY ML+R3YHZY+esu+weS5b8ZPL4+PQWSwBzFJdNSmpOZllqkb5dAlfG8TUrmQuOrmOvWLrkCmMD Y+s+ti5GTg4JAROJacsWs0PYYhIX7q0HinNxCAksZpK4+O0wI4SzgVHi79kmqMwDJonvXzYA ZTg4mAUSJPa2VYF08wroSby6dZkVxBYW8JG4ePoJmM0moCoxfU0LE4jNKWAn8e3GZ7A4i4CK xO6tzWBXMAukSSy6v4YJYo6VxOVJ71ghdk3mkmhobmQBSYgANXy7ep0R4lRZid2/HzFNYBSY hXDGLCRnzAIbqy2xbOFrZghbU2J/93IWTHENic5vE1kXMLKtYpRNya3SzU3MzClOTdYtTk7M y0st0rXQy80s0UtNKd3ECIoDdhfVHYwTDikdYhTgYFTi4ZVYGxMmxJpYVlyZe4hRkoNJSZRX /WVsmBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3kXPgXK8KYmVValF+TApaQ4WJXHeuV98w4QE 0hNLUrNTUwtSi2CyMhwcShK8a74ANQoWpaanVqRl5pQgpJk4OEGG8wANvwhSw1tckJhbnJkO kT/FqCglzrsdJCEAksgozYPrBaWphLeHTV8xigO9Isz7DKSKB5ji4LpfAQ1mAhr84U80yOCS RISUVAOj/fJ0uTqBnKfb58qtL7GduOdN1POGj4uaqtaFF+W8bLzK5CrmHCF2JzbBbI0Vv5cl 2+cGhXdC1WEFD2qlOidO3CVwe/qp29e/q0/5ZmscdmPVD4uWo169V8UXJN1ma+JK2r9zKdvG kBsZaxtX3tq4pmTim/PH69cFRa4MkhPw3Nu88MKkMG5BJZbijERDLeai4kQAmZ7DhC4DAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 19:32:59 -0000 --Apple-Mail=_4C323F63-FBBB-4B84-A9BF-44B98B3C8DD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is my proposal: A large range of threats can be mitigated by protecting the content of the token, for example using a digital signature or a keyed message digest. Alternatively, the content of the token could be passed by reference rather than by value (requiring a separate message exchange to resolve the reference to the token content). =20 To simplify discussion in the following example we assume that the token itself=20 cannot be modified by the client, either due to cryptographic protection (such as signature or encryption) or use of a reference value with sufficient entropy and associated secure lookup. =20 The token remains opaque to the client. These are characteristics shared with bearer tokens and more information on best practices can be found in [RFC6819] and in the security considerations section of [RFC6750]. =E2=80=94 Justin > On Dec 1, 2015, at 2:29 PM, Phil Hunt wrote: >=20 > Justin, >=20 > I was wondering why you put in the second sentence in bold. :-) >=20 > I=E2=80=99m not sure which one you want to take out. Would you post = the text exactly as you would like it? >=20 > Thanks, >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >> On Dec 1, 2015, at 11:21 AM, Justin Richer > wrote: >>=20 >> You=E2=80=99ve got =E2=80=9CThe token remains opaque to the client=E2=80= =9D in there twice now. I had cut out the middle part the first sentence = in the second paragraph below, but that was hard to highlight. If you = take my text as-is that=E2=80=99s what I meant for the edited form. >>=20 >> Thanks >> =E2=80=94 Justin >>=20 >>> On Dec 1, 2015, at 2:18 PM, Phil Hunt > wrote: >>>=20 >>> Including Justin=E2=80=99s revision: >>>=20 >>> A large range of threats can be mitigated by protecting the = content >>> of the token, for example using a digital signature or a keyed >>> message digest. Alternatively, the content of the token could be >>> passed by reference rather than by value (requiring a separate >>> message exchange to resolve the reference to the token content). >>>=20 >>> To simplify discussion in the following examples, we assume that = the >>> token itself is integrity protected by the authorization server = and >>> the token remains opaque to the client. The token itself cannot = be >>> modified by the client, either due to cryptographic protection = (such >>> as signature or encryption) or the use of a reference value with >>> sufficient entropy and associated secure lookup. The token = remains >>> opaque to the client. These are characteristics shared with = bearer >>> tokens and more information on best practices can be found in >>> [RFC6819] and in the security considerations section of = [RFC6750]. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com = phil.hunt@oracle.com = >>>> On Dec 1, 2015, at 10:35 AM, Phil Hunt > wrote: >>>>=20 >>>> Thanks Justin. Your tweaks look good to me. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com = phil.hunt@oracle.com = >>>>> On Dec 1, 2015, at 10:28 AM, Kathleen Moriarty = > wrote: >>>>>=20 >>>>> The changes work for me, thanks. >>>>>=20 >>>>> On Tue, Dec 1, 2015 at 1:27 PM, Justin Richer > wrote: >>>>> That=E2=80=99s much better. I would also suggest that a few edits = to hammer home that this is an example >>>>>=20 >>>>>> A large range of threats can be mitigated by protecting the = content >>>>>> of the token, for example using a digital signature or a keyed >>>>>> message digest. Alternatively, the content of the token could = be >>>>>> passed by reference rather than by value (requiring a separate >>>>>> message exchange to resolve the reference to the token = content). To >>>>>> simplify discussion in the following example we assume=20 >>>>>> that the token itself [=E2=80=A6] >>>>>> cannot be modified by the client, either due to cryptographic >>>>>> protection (such as signature or encryption) or use of a = reference >>>>>> value with sufficient entropy and associated secure lookup. = The token remains opaque to the client. >>>>>> These >>>>>> are characteristics shared with bearer tokens and more = information on >>>>>> best practices can be found in [RFC6819] and in the security >>>>>> considerations section of [RFC6750]. >>>>>=20 >>>>> That=E2=80=99s really what=E2=80=99s going on by my read. = Thoughts? >>>>>=20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>>> On Dec 1, 2015, at 1:08 PM, Phil Hunt > wrote: >>>>>>=20 >>>>>> I=E2=80=99ve reviewed the comments from John, Justin and = Kathleen. As suggested, I plan to remove the erroneous first paragraph = in section 5 (draft 06). >>>>>>=20 >>>>>> Combining the comments from this thread about sec 6, here is the = proposed new first paragraph: >>>>>>=20 >>>>>> A large range of threats can be mitigated by protecting the = content >>>>>> of the token, for example using a digital signature or a keyed >>>>>> message digest. Alternatively, the content of the token could = be >>>>>> passed by reference rather than by value (requiring a separate >>>>>> message exchange to resolve the reference to the token = content). To >>>>>> simplify the subsequent description we assume in the PoP = architecture >>>>>> that the token itself is integrity protected by the = authorization >>>>>> server and the token remains opaque to the client. The token = itself >>>>>> cannot be modified by the client, either due to cryptographic >>>>>> protection (such as signature or encryption) or use of a = reference >>>>>> value with sufficient entropy and associated secure lookup. = These >>>>>> are characteristics shared with bearer tokens and more = information on >>>>>> best practices can be found in [RFC6819] and in the security >>>>>> considerations section of [RFC6750]. >>>>>> If this looks good to the group, I=E2=80=99ll post draft 7 this = afternoon (pacific). >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>>> On Nov 25, 2015, at 2:19 PM, Kathleen Moriarty = > wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Wed, Nov 25, 2015 at 3:58 PM, John Bradley > wrote: >>>>>>> I am fine with that, however saying integrity protected, may be = better than signed. May people will argue that HMAC or encryption with = sender verification is not signature. >>>>>>>=20 >>>>>>> Good point, I also prefer integrity protected. Are we all good = with this now? I'd like to look at a diff to make sure after following = the thread. >>>>>>>=20 >>>>>>> Thanks! >>>>>>> Kathleen >>>>>>>=20 >>>>>>> =20 >>>>>>> However they are perfectly valid. >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Nov 25, 2015, at 5:53 PM, Justin Richer > wrote: >>>>>>>>=20 >>>>>>>> The requirement is not that signed JWTs be used, it=E2=80=99s = that unsigned JWTs not be used on their own. Reference tokens and = encrypted JWTs are also valid, as are other signed formats like SAML = assertions or even a COSE Token (if it=E2=80=99s encoded to HTTP = friendliness).=20 >>>>>>>>=20 >>>>>>>> My recommendation: >>>>>>>>=20 >>>>>>>> Remove the erroneous requirement text from section 5 and = restore to previous version. >>>>>>>>=20 >>>>>>>> Amend the text in section 6 from: >>>>>>>>=20 >>>>>>>> To >>>>>>>> simplify the subsequent description we assume in the PoP = architecture >>>>>>>> that the token itself is digitally signed by the = authorization server >>>>>>>> and therefore cannot be modified. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> To: >>>>>>>>=20 >>>>>>>> In all such cases, the token remains opaque to the client. = To >>>>>>>> simplify the subsequent example and description we assume in = the PoP architecture >>>>>>>> that the token itself cannot be modified by the client, = either due to >>>>>>>> cryptographic protection (such as signature or encryption) = or use of=20 >>>>>>>> a reference value with sufficient entropy and associated = secure lookup. >>>>>>>> These are characteristics shared with bearer tokens and more = information >>>>>>>> on best practices can be found in [[RFC6819]] and in the = security=20 >>>>>>>> considerations section of [[RFC6750]].=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> =E2=80=94 Justin >>>>>>>>=20 >>>>>>>>> On Nov 25, 2015, at 3:39 PM, Kathleen Moriarty = > wrote: >>>>>>>>>=20 >>>>>>>>> Hi, >>>>>>>>>=20 >>>>>>>>> Sent from my iPhone >>>>>>>>>=20 >>>>>>>>> On Nov 25, 2015, at 3:20 PM, John Bradley > wrote: >>>>>>>>>=20 >>>>>>>>>> Tokens are signed or the information is otherwise integrity = protected between the AS and the RS. =20 >>>>>>>>>>=20 >>>>>>>>>> I suspect Kathleen is concerned about the key getting = modified in transit. =20 >>>>>>>>>> That needs to be protected against, but there is more than = one way to do that. >>>>>>>>>=20 >>>>>>>>> Phil is correct. I was looking for consistency between the = sections since they related to each other. If there is a security risk = or consideration, that needs to be explicitly called out as a concern = such as a key being modified in transit. If there are options to = protect against that, those would ideally be required or would have = warnings. >>>>>>>>>>=20 >>>>>>>>>> So sending the public key in a unsigned JWT access token = would be immensely stupid, not just for PoP but for scopes and = everything else. >>>>>>>>>=20 >>>>>>>>> Good, easy to require then. >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> Kathleen=20 >>>>>>>>>>=20 >>>>>>>>>> In OAuth 2 all tokens need to be integrity protected between = the AS and RS. =20 >>>>>>>>>> That can be via signature, by having a reference with = sufficient entropy and secure introspection or database lookup. >>>>>>>>>>=20 >>>>>>>>>> I think that is a OAuth 2 security consideration. We are = adding a additional confirmation claim to the existing information that = needs to be protected the same as the rest. >>>>>>>>>>=20 >>>>>>>>>> John B. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> On Nov 25, 2015, at 4:38 PM, Phil Hunt > wrote: >>>>>>>>>>>=20 >>>>>>>>>>> >>>>>>>>>>> If there is agreement that tokens are opaque then the = requirement that tokens be signed must be removed from the threat = mitigation requirements.=20 >>>>>>>>>>>=20 >>>>>>>>>>> And the paragraph in sec 5 that brian was concerned about be = restored.=20 >>>>>>>>>>>=20 >>>>>>>>>>> Phil >>>>>>>>>>>=20 >>>>>>>>>>> On Nov 25, 2015, at 11:24, Justin Richer > wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> It is still end to end authentication with opaque tokens = =E2=80=94 since all OAuth tokens, including PoP tokens, have always been = intended to be opaque to the client. That hasn=E2=80=99t changed and = that isn=E2=80=99t the intent of this document. If that=E2=80=99s how = people are reading it then we need to pull it back and rewrite it so = that=E2=80=99s not the case. >>>>>>>>>>>>=20 >>>>>>>>>>>> The client gets a token that has two parts: the token and = the key. The token is analogous to the access_token we have today and = would come out of the server in the same field. The key is handed to the = client alongside the token or registered by the client during the token = request. Either way there=E2=80=99s an association between the two but = it=E2=80=99s not the same association as a public/private keypair.=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> It=E2=80=99s possible to sign the token itself, but the = client doesn=E2=80=99t care. It sends the token and signs the HTTP = request to the RS whether the token is signed, unsigned, hex blob, = encrypted, or anything else. The same series of options are available as = with bearer tokens. PoP tokens have never, ever been intended to be = anything but opaque to the client. >>>>>>>>>>>>=20 >>>>>>>>>>>> The token can=E2=80=99t be opaque to the RS, which has to = figure out what key to use to check the message signature. But we=E2=80=99= ve got options there, like the embedded key in a JWT from Mike=E2=80=99s = draft, or doing introspection to get the key (from an extension that = hasn=E2=80=99t been written yet), or simply looking it up in the same = database because the RS and the AS are in the same box. Does this = structure/service/database choice sound familiar? It should, it=E2=80=99s = the same as bearer tokens. This is also how the RS gets information like = which scopes are associated with the token, if it=E2=80=99s expired, and = all that.=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> So here=E2=80=99s how I see it going on the wire: >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> (I just wrote this up so there are probably holes. Here=E2=80= =99s the source if anyone wants to tweak it: = http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW50IGFzIEMKA= AwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3R= lY3RlZABICmFzIFJTCgoKClJPLS0 = -QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmV= jdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAK= QcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADA= FKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIA= E8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmN= sdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduY= XR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwB= iBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZ= CkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4= OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&= s=3Dmodern-blue ) >>>>>>>>>>>>=20 >>>>>>>>>>>> The client is oblivious to the token just like always. This = is intentional. The RS has the same options to figure out how to process = the token. >>>>>>>>>>>>=20 >>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>=20 >>>>>>>>>>>>> On Nov 25, 2015, at 2:03 PM, Phil Hunt = > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Folks,=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> >>>>>>>>>>>>> I did not want to go here either. :-) >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I don=E2=80=99t read sec 6 as examples. I believe this = may stem from the pop-architecture documents having a dual role as both = =E2=80=9Carchitecture=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D. Maybe we = should clarify the purpose of the document? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I believe section 6 is talking about threat mitigation = assumptions based on the examples that need to be implemented. I am = assuming these are requirements that the other specifications SHOULD = implement. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> >>>>>>>>>>>>> I do not believe we have discussed Opaque PoP tokens and = any inherent risks because the client is not or is unable to validate = the authenticity of the token. Does this introduce the possibility of a = MITM attack where a client can be convinced to sign requests for an = attacker? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> If we want to include opaque PoP, I think we need to take = a pause and consider / discuss any threats here. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I find the desire for opaque PoP tokens to be a bit = contradictory. If we=E2=80=99re saying we don=E2=80=99t want to trust = TLS alone (e.g. because of load-balancer termination), why would we then = say, but we are perfectly willing to accept it worked for the OAuth AS = exchanges? Maybe I was very wrong here, but my assumption all along is = that for PoP we=E2=80=99re talking about end-to-end authentication of = all parties except in the case of 3.3 where we simply want to protect an = access token over a non-TLS HTTP connection. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Phil >>>>>>>>>>>>>=20 >>>>>>>>>>>>> @independentid >>>>>>>>>>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>>>>>>>>>> On Nov 25, 2015, at 10:48 AM, Brian Campbell = > wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> While I can't say I disagree with the deeper existential = questions about the draft that Justin raises, I was trying not to go = there and rather just point out concerns with the newly added text.=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The text Phil cites from Sec 6 doesn't say the client = must be able to parse and verify the token. It's an assumption to = simplify the examples that follow and still the token is opaque to the = client. I reread the whole draft (reluctantly) and there's nothing that = says the token has to be non-opaque to the client. And it does talk = about reference style tokens and encrypted tokens, both of which rely on = the opaqueness to the client.=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer = > wrote: >>>>>>>>>>>>>> Right, I read that as text for describing the examples = and not for describing requirements. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The token itself doesn=E2=80=99t have to be signed at = all. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Nov 25, 2015, at 1:05 PM, Phil Hunt = > wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Ok. Well this was requested by Kathleen because of this = paragraph in Sec 6.=E2=80=A6 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> To simplify the subsequent description we assume in = the PoP architecture >>>>>>>>>>>>>>> that the token itself is digitally signed by the = authorization server >>>>>>>>>>>>>>> and therefore cannot be modified. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Please=20 >>>>>>>>>>>>>>> Phil >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> @independentid >>>>>>>>>>>>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>>>>>>>>>>>> On Nov 25, 2015, at 9:33 AM, Justin Richer = > wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The token doesn=E2=80=99t have to be signed and the = client doesn=E2=80=99t have to verify the signature on the token. = That=E2=80=99s not PoP. The request has to be signed in a way that = includes the token. The token itself can still be opaque. The *key* = material can=E2=80=99t be opaque to the client, but the *token* material = still is. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> I agree with Brian that this statement is misleading. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The examples use a signed token but that is absolutely = not a requirement. Maybe the examples shouldn=E2=80=99t all use one = style. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> What=E2=80=99s most difficult about this particular = spec is that it=E2=80=99s very hand-wavy, saying =E2=80=9Cthis is kinda = a thing that kinda works like this=E2=80=9D without saying how to = actually do it. I=E2=80=99m honestly not sure it=E2=80=99s worth = publishing as an RFC in its own right but I=E2=80=99m not going to stand = in its way. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On Nov 25, 2015, at 12:14 PM, Brian Campbell = > wrote: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Where does it say that?=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt = > wrote: >>>>>>>>>>>>>>>>> Except that later on we require the token be signed = and the client verify that signed token. IOW mutual pop.=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Phil >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On Nov 25, 2015, at 07:30, Brian Campbell = > wrote: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Looking at the diff I noticed the following new text, = which seems to conflate bearer/PoP and opaqueness to the client. A = client demonstrating proof-of-possession of some key is orthogonal to = the client being able to parse and understand the access token itself.=20= >>>>>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>>>>> "In contrast to bearer tokens [RFC6750] which call = for tokens that are opaque to OAuth 2.0 clients, this specification = defines the requirements for proof-of-possession ("PoP") tokens that may = be parsed and verified by OAuth 2.0 clients and relying parties." >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt = > wrote: >>>>>>>>>>>>>>>>>> This draft addresses review comments from Kathleen = and Erik raised since the last draft. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> It may not include some of the discussion from = yesterday/today. I will add that as the group decides. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Phil >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> @independentid >>>>>>>>>>>>>>>>>> www.independentid.com >>>>>>>>>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> > On Nov 24, 2015, at 12:05 PM, = internet-drafts@ietf.org wrote: >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>>>>>>>>>>>>> > This draft is a work item of the Web Authorization = Protocol Working Group of the IETF. >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > Title : OAuth 2.0 = Proof-of-Possession (PoP) Security Architecture >>>>>>>>>>>>>>>>>> > Authors : Phil Hunt >>>>>>>>>>>>>>>>>> > Justin Richer >>>>>>>>>>>>>>>>>> > William Mills >>>>>>>>>>>>>>>>>> > Prateek Mishra >>>>>>>>>>>>>>>>>> > Hannes Tschofenig >>>>>>>>>>>>>>>>>> > Filename : = draft-ietf-oauth-pop-architecture-06.txt >>>>>>>>>>>>>>>>>> > Pages : 23 >>>>>>>>>>>>>>>>>> > Date : 2015-11-24 >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > 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 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. >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > The IETF datatracker status page for this draft is: >>>>>>>>>>>>>>>>>> > = https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ = >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > There's also a htmlized version available at: >>>>>>>>>>>>>>>>>> > = https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 = >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > A diff from the previous version is available at: >>>>>>>>>>>>>>>>>> > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 = = >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > 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 . >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > Internet-Drafts are also available by anonymous FTP = at: >>>>>>>>>>>>>>>>>> > ftp://ftp.ietf.org/internet-drafts/ = >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>>>>>>>> > OAuth mailing list >>>>>>>>>>>>>>>>>> > OAuth@ietf.org >>>>>>>>>>>>>>>>>> > https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>>>>>> =09= >>>>>>>>>>>>>>>>>> Brian Campbell >>>>>>>>>>>>>>>>>> Distinguished Engineer >>>>>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>>>>>>>>> @pingidentity >>>>>>>>>>>>>>>>>> Connect with us! >>>>>>>>>>>>>>>>>> = >>>>>>>>>>>>>>>>>> = = = = = = = = = >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>>>>> =09= >>>>>>>>>>>>>>>>> Brian Campbell >>>>>>>>>>>>>>>>> Distinguished Engineer >>>>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>>>>>>>> @pingidentity >>>>>>>>>>>>>>>>> Connect with us! >>>>>>>>>>>>>>>>> = >>>>>>>>>>>>>>>>> = = = = = = = = = _____________________________________= __________ >>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>> =09= >>>>>>>>>>>>>> Brian Campbell >>>>>>>>>>>>>> Distinguished Engineer >>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>>>>> @pingidentity >>>>>>>>>>>>>> Connect with us! >>>>>>>>>>>>>> = >>>>>>>>>>>>>> = = = = = = = = = >>>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> --=20 >>>>>>>=20 >>>>>>> Best regards, >>>>>>> Kathleen >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>>=20 >>>>> Best regards, >>>>> Kathleen >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >=20 --Apple-Mail=_4C323F63-FBBB-4B84-A9BF-44B98B3C8DD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
This is my proposal:

A large range of threats can be mitigated by protecting the = content
 =  of the token, for example using a digital signature or a = keyed
  =  message digest.  Alternatively, the content of the token = could be
   passed by reference rather than by value = (requiring a separate
   message exchange to resolve the reference to the = token content).  

   To simplify discussion in the = following example
   we assume that the token = itself 
   cannot be modified by the client, either due to = cryptographic
   protection (such as signature or encryption) or = use of a reference
   value with sufficient entropy and associated = secure lookup.  
  =  The token remains opaque to the client. These
   are = characteristics shared with bearer tokens and more information = on
  =  best practices can be found in [RFC6819] and in the = security
   considerations section of = [RFC6750].



 =E2=80=94 Justin

On Dec 1, 2015, at 2:29 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:

Justin,

I was wondering why you = put in the second sentence in bold. :-)

I=E2=80=99m not sure which one you want = to take out. Would you post the text exactly as you would like = it?

Thanks,


On Dec 1, 2015, at 11:21 AM, Justin Richer <jricher@mit.edu> = wrote:

You=E2=80=99ve got = =E2=80=9CThe token remains opaque to the client=E2=80=9D in there twice = now. I had cut out the middle part the first sentence in the second = paragraph below, but that was hard to highlight. If you take my text = as-is that=E2=80=99s what I meant for the edited form.

Thanks
 =E2=80=94= Justin

On Dec 1, 2015, at 2:18 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:

Including Justin=E2=80=99= s revision:

  A =
large range of threats can be mitigated by protecting the content
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).

   To simplify discussion in the following examples, we assume that the
   token itself is integrity protected by the authorization server and
   the token remains opaque to the client.  The token itself cannot be
   modified by the client, either due to cryptographic protection (such
   as signature or encryption) or the use of a reference value with
   sufficient entropy and associated secure lookup.  The token remains
   opaque to the client.  These are characteristics shared with bearer
   tokens and more information on best practices can be found in
   [RFC6819] and in the security considerations section of [RFC6750].


On Dec 1, 2015, at 10:35 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Thanks Justin. Your = tweaks look good to me.


On Dec 1, 2015, at 10:28 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

The changes work for me, thanks.

On Tue, = Dec 1, 2015 at 1:27 PM, Justin Richer <jricher@mit.edu> wrote:
That=E2=80=99s much better. I would also suggest that a few = edits to hammer home that this is an example

 A large range of threats can =
be mitigated by protecting the content
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).  To
   simplify discussion=
 in the following example we assume=20
   that the token itself [=E2=80=A6]
   cannot be modified by the client, either due to cryptographic
   protection (such as signature or encryption) or use of a reference
   value with sufficient entropy and associated secure lookup.  =
The token remains =
opaque to the client.
These
   are characteristics shared with bearer tokens and more information on
   best practices can be found in [RFC6819] and in the security
   considerations section of =
[RFC6750].

That=E2=80=99s really what=E2=80=99s going on by my read. = Thoughts?

 =E2=80= =94 Justin

On Dec 1, 2015, at 1:08 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

I=E2=80=99ve reviewed the = comments from John, Justin and Kathleen. As suggested, I plan to remove = the erroneous first paragraph in section 5 (draft 06).

Combining the comments from this thread = about sec 6, here is the proposed new first paragraph:

 A large =
range of threats can be mitigated by protecting the content
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).  To
   simplify the subsequent description we assume in the PoP architecture
   that the token itself is integrity protected by the authorization
   server and the token remains opaque to the client.  The token itself
   cannot be modified by the client, either due to cryptographic
   protection (such as signature or encryption) or use of a reference
   value with sufficient entropy and associated secure lookup.  These
   are characteristics shared with bearer tokens and more information on
   best practices can be found in [RFC6819] and in the security
   considerations section of [RFC6750].
If this = looks good to the group, I=E2=80=99ll post draft 7 this afternoon = (pacific).

Thanks,


On Nov 25, 2015, at 2:19 PM, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> wrote:



On Wed, = Nov 25, 2015 at 3:58 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I am fine with that, however = saying integrity protected, may be better than signed.  May people = will argue that HMAC or encryption with sender verification is not = signature.

Good point, I also prefer integrity protected.  Are we = all good with this now?  I'd like to look at a diff to make sure = after following the thread.

Thanks!
Kathleen
 
However they are perfectly valid.


On Nov 25, 2015, at 5:53 PM, Justin Richer = <jricher@mit.edu> wrote:

The = requirement is not that signed JWTs be used, it=E2=80=99s that unsigned = JWTs not be used on their own. Reference tokens and encrypted JWTs are = also valid, as are other signed formats like SAML assertions or even a = COSE Token (if it=E2=80=99s encoded to HTTP friendliness). 

My = recommendation:

Remove the erroneous requirement text from section 5 and = restore to previous version.

Amend the text in section 6 = from:

   To
   simplify the subsequent description we assume in the PoP architecture

   that the token itself is digitally signed by =
the authorization server
   and therefore cannot be modified.


To:

   In all such cases, the token remains =
opaque to the client. To
   simplify the subsequent example and description we assume in the PoP =
architecture
   that the token itself cannot be =
modified by the client, either due to
   =
cryptographic protection (such as signature or encryption) or use =
of 
   a reference value with sufficient =
entropy and associated secure lookup.
   These are =
characteristics shared with bearer tokens and more information
   on best practices can be found in [[RFC6819]] and in the =
security 
   considerations section of =
[[RFC6750]].


 =E2=80=94 = Justin

On Nov 25, 2015, at 3:39 PM, = Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> = wrote:

Hi,

Sent from my iPhone

On = Nov 25, 2015, at 3:20 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Tokens are signed or the information is otherwise integrity = protected between the AS and the RS.  

I suspect Kathleen is concerned about = the key getting modified in transit.   
That needs to be protected against, but there is more than = one way to do that.

Phil is correct.  I was looking for consistency = between the sections since they related to each other.  If there is = a security risk or consideration, that needs to be explicitly called out = as a concern such as a key being modified in transit.  If there are = options to protect against that, those would ideally be required or = would have warnings.

So sending the public key in a unsigned JWT access token = would be immensely stupid,  not just for PoP but for scopes and = everything else.

Good, easy to require then.

Thanks,
Kathleen 

In OAuth 2 all tokens need to be integrity protected between = the AS and RS.  
That can be via signature, =  by having a reference with sufficient entropy and secure = introspection or database lookup.

I think that is a OAuth 2 security = consideration.   We are adding a additional confirmation claim to = the existing information that needs to be protected the same as the = rest.

John = B.


On Nov 25, 2015, at 4:38 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

<editors = hat>
If there is agreement that tokens are = opaque then the requirement that tokens be signed must be removed from = the threat mitigation requirements. 

And the paragraph in sec 5 that brian = was concerned about be restored. 

Phil

On Nov 25, 2015, at 11:24, Justin Richer <jricher@mit.edu> wrote:

It = is still end to end authentication with opaque tokens =E2=80=94 since = all OAuth tokens, including PoP tokens, have always been intended to be = opaque to the client. That hasn=E2=80=99t changed and that isn=E2=80=99t = the intent of this document. If that=E2=80=99s how people are reading it = then we need to pull it back and rewrite it so that=E2=80=99s not the = case.

The client = gets a token that has two parts: the token and the key. The token is = analogous to the access_token we have today and would come out of the = server in the same field. The key is handed to the client alongside the = token or registered by the client during the token request. Either way = there=E2=80=99s an association between the two but it=E2=80=99s not the = same association as a public/private keypair. 

It=E2=80=99s possible to = sign the token itself, but the client doesn=E2=80=99t care. It sends the = token and signs the HTTP request to the RS whether the token is signed, = unsigned, hex blob, encrypted, or anything else. The same series of = options are available as with bearer tokens. PoP tokens have never, ever = been intended to be anything but opaque to the client.

The token can=E2=80=99t = be opaque to the RS, which has to figure out what key to use to check = the message signature. But we=E2=80=99ve got options there, like the = embedded key in a JWT from Mike=E2=80=99s draft, or doing introspection = to get the key (from an extension that hasn=E2=80=99t been written yet), = or simply looking it up in the same database because the RS and the AS = are in the same box. Does this structure/service/database choice sound = familiar? It should, it=E2=80=99s the same as bearer tokens. This is = also how the RS gets information like which scopes are associated with = the token, if it=E2=80=99s expired, and all that. 




So here=E2=80=99s how I see it going on the wire:



3D"http://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DcGFydGljaXBhb=



(I just wrote this up so = there are probably holes. Here=E2=80=99s the source if anyone wants to = tweak it: http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW= 50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZB= UwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPl= JPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAV= BwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcm= VxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsA= EAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUz= ogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVj= awCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludH= Jvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGlj= IG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAI= QoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiBy= ZXR1cm4AhicJ&s=3Dmodern-blue )

The client is oblivious to the token = just like always. This is intentional. The RS has the same options to = figure out how to process the token.

 =E2=80=94 Justin

On Nov 25, 2015, at 2:03 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Folks, 

<editor = hat>
I did not want to go here either. = :-)

I don=E2=80=99= t read sec 6 as examples.  I believe this may stem from the = pop-architecture documents having a dual role as both =E2=80=9Carchitectur= e=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D.  Maybe we should clarify = the purpose of the document?

I believe section 6 is talking about = threat mitigation assumptions based on the examples that need to be = implemented.  I am assuming these are requirements that the other = specifications SHOULD implement.

<personal hat>
I do not believe we have discussed Opaque PoP tokens and any = inherent risks because the client is not or is unable to validate the = authenticity of the token.  Does this introduce the possibility of = a MITM attack where a client can be convinced to sign requests for an = attacker?

If = we want to include opaque PoP, I think we need to take a pause and = consider / discuss any threats here.

I find the desire for opaque PoP tokens = to be a bit contradictory. If we=E2=80=99re saying we don=E2=80=99t want = to trust TLS alone (e.g. because of load-balancer termination), why = would we then say, but we are perfectly willing to accept it worked for = the OAuth AS exchanges?  Maybe I was very wrong here, but my = assumption all along is that for PoP we=E2=80=99re talking about = end-to-end authentication of all parties except in the case of 3.3 where = we simply want to protect an access token over a non-TLS HTTP = connection.



On Nov 25, 2015, at 10:48 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

While I can't say I disagree with the deeper = existential questions about the draft that Justin raises, I was trying = not to go there and rather just point out concerns with the newly added = text.

The text Phil cites from Sec 6 = doesn't say the client must be able to parse and verify the token. It's = an assumption to simplify the examples that follow and still the token = is opaque to the client. I reread the whole draft (reluctantly) and = there's nothing that says the token has to be non-opaque to the client. = And it does talk about reference style tokens and encrypted tokens, both = of which rely on the opaqueness to the client.

On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer = <jricher@mit.edu> wrote:
Right, I read that as text for = describing the examples and not for describing requirements.

The token itself = doesn=E2=80=99t have to be signed at all.

 =E2=80=94 Justin

On Nov 25, 2015, at 1:05 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:

Ok. Well this was = requested by Kathleen because of this paragraph in Sec 6.=E2=80=A6

   =
To simplify the subsequent description we assume in the PoP =
architecture
   =
that the token itself is digitally signed by the authorization server

   and therefore cannot be modified.

Please 

On Nov 25, 2015, at 9:33 AM, Justin Richer <jricher@mit.edu> wrote:

The token = doesn=E2=80=99t have to be signed and the client doesn=E2=80=99t have to = verify the signature on the token. That=E2=80=99s not PoP. The request = has to be signed in a way that includes the token. The token itself can = still be opaque. The *key* material can=E2=80=99t be opaque to the = client, but the *token* material still is.

I agree with Brian that this statement = is misleading.

The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one = style.

What=E2=80= =99s most difficult about this particular spec is that it=E2=80=99s very = hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda works like = this=E2=80=9D without saying how to actually do it. I=E2=80=99m honestly = not sure it=E2=80=99s worth publishing as an RFC in its own right but = I=E2=80=99m not going to stand in its way.

 =E2=80=94 Justin

On Nov 25, 2015, at 12:14 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

Where does it say = that?



On Wed, = Nov 25, 2015 at 8:44 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Except that later on we require the token be = signed and the client verify that signed token. IOW mutual = pop. 

Phil

On Nov 25, 2015, at 07:30, = Brian Campbell <bcampbell@pingidentity.com> = wrote:

Looking at the = diff I noticed the following new text, which seems to conflate = bearer/PoP and opaqueness to the client. A client demonstrating = proof-of-possession of some key is orthogonal to the client being able = to parse and understand the access token itself.
 
"In contrast to bearer tokens [RFC6750] which call for tokens = that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
This draft = addresses review comments from Kathleen and Erik raised since the last = draft.

It may not include some of the discussion from yesterday/today.  I = will add that as the group decides.

Cheers,

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF.
>
>        Title          =  : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors        =  : Phil Hunt
>                  =         Justin Richer
>                  =         William Mills
>                  =         Prateek Mishra
>                  =         Hannes Tschofenig
>       Filename        : = draft-ietf-oauth-pop-architecture-06.txt
>       Pages          =  : 23
>       Date          =   : 2015-11-24
>
> 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 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.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth






--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


________________________________= _______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
________________________________= _______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





--

Best regards,
Kathleen
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--

Best regards,
Kathleen

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



= --Apple-Mail=_4C323F63-FBBB-4B84-A9BF-44B98B3C8DD5-- From nobody Tue Dec 1 11:39:41 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4E21B2F7E for ; Tue, 1 Dec 2015 11:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zW1a008LFGBz for ; Tue, 1 Dec 2015 11:39:32 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0794.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::794]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 546D31B2F71 for ; Tue, 1 Dec 2015 11:39:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QBXDQXo6zmatoshQydUnfL62A9Qoc5jjQ10RAKNFdUw=; b=fe5Q5dioQb5NDaTM2jQ1+TEbok9rl2Z+02elgIgiSPjmZWsKpuyHsUm7rJ7kOIREidhXPdlDvF41XiWmuuYH+0FRIu/G0IEnxpPu1Rb60lcrHVDB08JFVs0pBcvKAed8VCNzC+dLO9KnErtY03ApZUhZhxKofFKFHA0sHMNrAQ8= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 1 Dec 2015 19:39:13 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Tue, 1 Dec 2015 19:39:13 +0000 From: Mike Jones To: Kathleen Moriarty Thread-Topic: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession Thread-Index: AQHRJt++kWDp0FqlfEmPEzc+Ih7voJ6r6UxQgAAee4CAAAb2QIAAAjcAgAAA9fCAALluAIAJxh2g Date: Tue, 1 Dec 2015 19:39:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [131.107.159.116] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:vYfuGWYw8bzEHCvjbeDJlKwodJbSEXGaIk/NSmaMn/Fo0z4ghD2BZb5tjCvvLTr6bGReWAuHfct/I/nXNBgLLmB7d6Vk9PBIcpKURvAjtBGnLb7nISBm2ykT4XrKH0SiioCmGJP7Pd0HelvUNun4bA==; 24:keJH76s9nmDAlx6VYdm7QcBPXsmY5zXCeFsKGrAeIsxRlMXkgcnEQ38La8/8LIoK5q7RqjymT88Il14/BMDLngoM/WFuHVpVEVkTYfebYsA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 07778E4001 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(43784003)(164054003)(13464003)(377454003)(189002)(51914003)(199003)(87936001)(8990500004)(5003600100002)(5002640100001)(2900100001)(5005710100001)(105586002)(50986999)(10400500002)(15975445007)(33656002)(106356001)(74316001)(5004730100002)(99286002)(40100003)(77096005)(5003630100001)(5008740100001)(122556002)(2950100001)(230783001)(10290500002)(86362001)(106116001)(66066001)(102836003)(81156007)(92566002)(76176999)(54356999)(76576001)(110136002)(189998001)(19580395003)(86612001)(586003)(19580405001)(1220700001)(93886004)(11100500001)(3846002)(6116002)(1096002)(10090500001)(101416001)(5001960100002)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2015 19:39:13.2571 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 19:39:38 -0000 Hi Kathleen, As you saw, I posted draft -08 yesterday with the additional security consi= derations John, you, and I had discussed. I wanted to check in with you an= d see if that addresses the point you were going to make in your ballot or = whether there is more you'd like us to do before the IETF review. Best wishes, -- Mike -----Original Message----- From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]=20 Sent: Wednesday, November 25, 2015 6:21 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession Hi Mike, If the working group is okay with the current text, leave it. What you pro= posed is exactly the same as what is there. I'll note this point in my bal= lot as I think you are leaving ambiguity that is not necessary. After getting far enough on this, I think it was Pete who discussed this wi= th you and he gave up and remained in disagreement. Regards, Kathleen=20 Sent from my iPhone > On Nov 24, 2015, at 10:25 PM, Mike Jones wr= ote: >=20 > Rather than elaborating, having looked at the text we're discussing again= , I'm going to counter-propose that we instead simplify - sticking only to = the point that the paragraph is intending to get across. Would it work for= you to simplify the current text: >=20 > "A recipient might not understand the cnf claim, in which case it will= typically be ignored. Unless this is acceptable behavior, applications tha= t need the proof-of-possession keys communicated with it to be understood a= nd processed must require that the parts of this specification that they us= e be implemented." >=20 > to this simpler text? >=20 > "A recipient might not understand the cnf claim. Applications that ne= ed the proof-of-possession keys communicated with it to be understood and p= rocessed must require that the parts of this specification that they use be= implemented." >=20 > The "must ignore" topic is already addressed in the second paragraph of 3= .1 (and with exactly the semantics as the rest of JWT), and so doesn't have= to be re-raised here, as it currently is. Re-raising it is clearly a poin= t of distraction. >=20 > For what it's worth, I don't remember any DISCUSSes on this topic (althou= gh it's possible that your memory is better than mine on this point). >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] > Sent: Tuesday, November 24, 2015 7:14 PM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] AD review of=20 > draft-ietf-oauth-proof-of-possession >=20 >> On Tue, Nov 24, 2015 at 10:10 PM, Mike Jones wrote: >> Fair question about the use of "typically". The reason it's there is th= at this language in JWT [RFC 7519] Section 4 does permit applications to re= quire that JWTs with not-understood claims be rejected, rather than ignored= , even though that's not the default behavior: >>=20 >> The set of claims that a JWT must contain to be considered valid is >> context dependent and is outside the scope of this specification. >> Specific applications of JWTs will require implementations to >> understand and process some claims in particular ways. However, in >> the absence of such requirements, all claims that are not understood >> by implementations MUST be ignored. >>=20 >> So when not understood, "cnf" would typically be ignored, but might not = be. >=20 > I find that confusing and am now thinking this came up in a discuss as we= ll during the review for 7519, didn't it? Can you elaborate int eh securit= y considerations section a bit more, otherwise this text appears to be conf= licting and even with what you intend, it's confusing for implementers and = will lead to issues with interoperability. >=20 > Thanks, > Kathleen >=20 >=20 >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] >> Sent: Tuesday, November 24, 2015 6:41 PM >> To: Mike Jones >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] AD review of=20 >> draft-ietf-oauth-proof-of-possession >>=20 >> Hi Mike, >>=20 >> Thanks for the quick turn-around. Just one more comment on my comments. >>=20 >>> On Tue, Nov 24, 2015 at 9:10 PM, Mike Jones wrote: >>> Thanks for your review comments, Kathleen. Responses are inline below.= .. >>>=20 >>>> -----Original Message----- >>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen=20 >>>> Moriarty >>>> Sent: Tuesday, November 24, 2015 9:44 AM >>>> To: oauth@ietf.org >>>> Subject: [OAUTH-WG] AD review of >>>> draft-ietf-oauth-proof-of-possession >>>>=20 >>>> Hi, >>>>=20 >>>> Thank you all for your work on this draft! I just have a few question= s: >>>>=20 >>>> 1. Security considerations section says: >>>>=20 >>>> "All of the normal security issues, especially in relationship to >>>> comparing URIs and dealing with unrecognized values, that are >>>> discussed in JWT [JWT] also apply here." >>>>=20 >>>> I find that to be odd phrasing that would likely be picked up in=20 >>>> subsequent reviews. Please remove the word "normal" so that all of=20 >>>> the security issues discusses in JWT are included. Are there other=20 >>>> 'normal considerations in addition to those in JWT that need to be=20 >>>> listed? The phrasing reads as if that may the case and would be=20 >>>> better to include them all or pointers or change the phrasing. >>>=20 >>> You're right. I removed this awkward wording. >>>=20 >>>> 2. Also in the security considerations section, >>>>=20 >>>> "A recipient may not understand the newly introduced "cnf" claim and >>>> may consequently treat it as a bearer token." >>>>=20 >>>> What is the proper handling requirement when an unknown claim is=20 >>>> present? Section 3.1 says: >>>> "When a recipient receives a "cnf" claim with a >>>> member that it does not understand, it MUST ignore that member." >>>>=20 >>>> Is this why it is treated as a bearer token rather than being=20 >>>> rejected? Is this really the action you want to see with cnf? Why=20 >>>> isn't there an error and a resend as a bearer token so that parties=20 >>>> understand (or have an opportunity to understand) that there were issu= es? >>>>=20 >>>> Then the following text in the security section says: >>>> "While this is a >>>> legitimate concern, it is outside the scope of this specification, >>>> since demonstration the possession of the key associated with the >>>> "cnf" claim is not covered by this specification. For more=20 >>>> details, >>>>=20 >>>> How is this outside of the scope of this draft? cnf is defined in=20 >>>> this draft, so handling should be covered in this draft. A pointer=20 >>>> to the POP architecture draft is not helpful as it is not defined=20 >>>> there, it's covered int his draft. Should this text just be=20 >>>> removed and replaced with more explicit handling information int he bo= dy of this draft? >>>=20 >>> Good catch. JWT [RFC 7519] Section 4 says that claims that are not und= erstood must be ignored unless otherwise specified by the application. Thi= s allows new claims to be dynamically added without breaking existing appli= cations. For the same reason, I have incorporated this language about unde= rstanding claims from 7519, but having it be about understanding confirmati= on members. Ultimately, what features must be implemented are always up to= the application, just as with JWT claims. >>=20 >> The new text in Section 3.1 looks good. I'm not sure why the word "typi= cally" appears int he new text of the security considerations section thoug= h after reading the new text in 3.1. Wouldn't it just be ignored since 3.1= now says: >>=20 >> "However, in the absence of such requirements, >> all confirmation members that are not understood by implementations >> MUST be ignored." >>=20 >> Thanks, >> Kathleen >>=20 >>=20 >>>=20 >>>> Thanks! >>>>=20 >>>> -- >>>>=20 >>>> Best regards, >>>> Kathleen >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> Thanks again, >>> -- Mike >>=20 >>=20 >>=20 >> -- >>=20 >> Best regards, >> Kathleen >=20 >=20 >=20 > -- >=20 > Best regards, > Kathleen From nobody Tue Dec 1 14:28:32 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6E91A1EEE for ; Tue, 1 Dec 2015 14:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6ydhYYv7Fac for ; Tue, 1 Dec 2015 14:28:21 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3595B1A1B85 for ; Tue, 1 Dec 2015 14:28:21 -0800 (PST) Received: by qkfo3 with SMTP id o3so9212880qkf.1 for ; Tue, 01 Dec 2015 14:28:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=uMlPZdNQ9NVxR6LOfCPtQgsKBwby9DTb9dM9iwVisuE=; b=rumfWLr/Y5cpEBPQHG0nTYJ9cgpEq6VkYzVQiDbwvR91rd9gWstQiQonPV/KjfgCGi DWg1Hcxj7bMF8iwmZQm5thd7lhctK+pdPBNGfrMh9Ih0JNGCx9DpLrFt7CfyVSSO6i42 WVv2gDbUQuwCsOM5kuminveYQ47ld39D9l6B7rnKdqp2d9kLZiXWRnHLpUpR32eeq7aW LvEEyC4QNmFqriihx/1tAAY4gooVv7TEoRLJ0jLfBYg28BYDEsvtNHrGb8n/2SIgelGz DIoMUzm+a/sVU2UApUx4XLV0PCe5YrN10FMIk/vi5sFdQMGTh8hyMvlXttxT7s+meMcC 2nVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=uMlPZdNQ9NVxR6LOfCPtQgsKBwby9DTb9dM9iwVisuE=; b=F2szPR5V/EtQiEzSZvtBkIjN5tX5mwzCKPIRsZX4cuTzZKT7ZgqGNP72BuQZWWz/SP laU3nunAQWzCIV5kb+Du+CjeYoOf3GdPSw2Xykjw3+bh8XXqhqpwajABga5qb16aiNO/ rN4dabtkDwIWCNywLUrwBeBC7bMDnmihIjim1lPfAymvzyMUyb3D9jWux9uE0irS6dS0 mVYUuRWNmybGtC7igLXeutBnRZM4Ttf6MBWPWjqPTCwEhti8nhRS3QWzqZHZcDre6T8Y 4jj3kGhnEFQhZrub47u3ttakmLlgICN+kpf3lHiOFKS54yt/o9nPVBQ+/GlmuT7Of7AG q+Mg== X-Gm-Message-State: ALoCoQkizbXObbiaBZS3ehkR/gzx6x1NVPmyYQEARHGQd/AcRLyKQbYls9OkynppnrO5o/9Xx4si X-Received: by 10.55.76.8 with SMTP id z8mr85837528qka.30.1449008900115; Tue, 01 Dec 2015 14:28:20 -0800 (PST) Received: from [192.168.1.216] ([191.115.54.54]) by smtp.gmail.com with ESMTPSA id 139sm10747117qhz.0.2015.12.01.14.28.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Dec 2015 14:28:18 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_60C1A29F-3730-40D6-9C13-48FEA051CAFC" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: Date: Tue, 1 Dec 2015 19:28:10 -0300 Message-Id: References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> <1AD1F44B-9837-4288-9997-5292F1DBE30E@oracle.com> <9E20E73C-AC35-4E03-A011-119A32CD0BF1@ve7jtb.com> <7431079B-818C-46E9-8102-D193E49384B2@gmail.com> <638FA321-4DE1-467C-9B5C-3BEA0EC3EB0F@mit.edu> <207E620F-97AA-4851-8776-2A7B1921D58A@ve7jtb.com> <8F038A71-! ! C047- 42F6-9BA9-D697A14902E1@mit.edu> <9F9526D9-A32A-4E34-A54D-8CC47A15E862@oracle.com> <6636599A-B628-4ABE-88A9-911219501096@oracle.com> To: Justin Richer X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 22:28:30 -0000 --Apple-Mail=_60C1A29F-3730-40D6-9C13-48FEA051CAFC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That looks good to me. > On Dec 1, 2015, at 4:21 PM, Justin Richer wrote: >=20 > You=E2=80=99ve got =E2=80=9CThe token remains opaque to the client=E2=80= =9D in there twice now. I had cut out the middle part the first sentence = in the second paragraph below, but that was hard to highlight. If you = take my text as-is that=E2=80=99s what I meant for the edited form. >=20 > Thanks > =E2=80=94 Justin >=20 >> On Dec 1, 2015, at 2:18 PM, Phil Hunt > wrote: >>=20 >> Including Justin=E2=80=99s revision: >>=20 >> A large range of threats can be mitigated by protecting the content >> of the token, for example using a digital signature or a keyed >> message digest. Alternatively, the content of the token could be >> passed by reference rather than by value (requiring a separate >> message exchange to resolve the reference to the token content). >>=20 >> To simplify discussion in the following examples, we assume that = the >> token itself is integrity protected by the authorization server = and >> the token remains opaque to the client. The token itself cannot = be >> modified by the client, either due to cryptographic protection = (such >> as signature or encryption) or the use of a reference value with >> sufficient entropy and associated secure lookup. The token = remains >> opaque to the client. These are characteristics shared with = bearer >> tokens and more information on best practices can be found in >> [RFC6819] and in the security considerations section of [RFC6750]. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com = phil.hunt@oracle.com = >>> On Dec 1, 2015, at 10:35 AM, Phil Hunt > wrote: >>>=20 >>> Thanks Justin. Your tweaks look good to me. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com = phil.hunt@oracle.com = >>>> On Dec 1, 2015, at 10:28 AM, Kathleen Moriarty = > wrote: >>>>=20 >>>> The changes work for me, thanks. >>>>=20 >>>> On Tue, Dec 1, 2015 at 1:27 PM, Justin Richer > wrote: >>>> That=E2=80=99s much better. I would also suggest that a few edits = to hammer home that this is an example >>>>=20 >>>>> A large range of threats can be mitigated by protecting the = content >>>>> of the token, for example using a digital signature or a keyed >>>>> message digest. Alternatively, the content of the token could = be >>>>> passed by reference rather than by value (requiring a separate >>>>> message exchange to resolve the reference to the token = content). To >>>>> simplify discussion in the following example we assume=20 >>>>> that the token itself [=E2=80=A6] >>>>> cannot be modified by the client, either due to cryptographic >>>>> protection (such as signature or encryption) or use of a = reference >>>>> value with sufficient entropy and associated secure lookup. = The token remains opaque to the client. >>>>> These >>>>> are characteristics shared with bearer tokens and more = information on >>>>> best practices can be found in [RFC6819] and in the security >>>>> considerations section of [RFC6750]. >>>>=20 >>>> That=E2=80=99s really what=E2=80=99s going on by my read. Thoughts? >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Dec 1, 2015, at 1:08 PM, Phil Hunt > wrote: >>>>>=20 >>>>> I=E2=80=99ve reviewed the comments from John, Justin and Kathleen. = As suggested, I plan to remove the erroneous first paragraph in section = 5 (draft 06). >>>>>=20 >>>>> Combining the comments from this thread about sec 6, here is the = proposed new first paragraph: >>>>>=20 >>>>> A large range of threats can be mitigated by protecting the = content >>>>> of the token, for example using a digital signature or a keyed >>>>> message digest. Alternatively, the content of the token could = be >>>>> passed by reference rather than by value (requiring a separate >>>>> message exchange to resolve the reference to the token = content). To >>>>> simplify the subsequent description we assume in the PoP = architecture >>>>> that the token itself is integrity protected by the = authorization >>>>> server and the token remains opaque to the client. The token = itself >>>>> cannot be modified by the client, either due to cryptographic >>>>> protection (such as signature or encryption) or use of a = reference >>>>> value with sufficient entropy and associated secure lookup. = These >>>>> are characteristics shared with bearer tokens and more = information on >>>>> best practices can be found in [RFC6819] and in the security >>>>> considerations section of [RFC6750]. >>>>> If this looks good to the group, I=E2=80=99ll post draft 7 this = afternoon (pacific). >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>> On Nov 25, 2015, at 2:19 PM, Kathleen Moriarty = > wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Wed, Nov 25, 2015 at 3:58 PM, John Bradley > wrote: >>>>>> I am fine with that, however saying integrity protected, may be = better than signed. May people will argue that HMAC or encryption with = sender verification is not signature. >>>>>>=20 >>>>>> Good point, I also prefer integrity protected. Are we all good = with this now? I'd like to look at a diff to make sure after following = the thread. >>>>>>=20 >>>>>> Thanks! >>>>>> Kathleen >>>>>>=20 >>>>>> =20 >>>>>> However they are perfectly valid. >>>>>>=20 >>>>>>=20 >>>>>>> On Nov 25, 2015, at 5:53 PM, Justin Richer > wrote: >>>>>>>=20 >>>>>>> The requirement is not that signed JWTs be used, it=E2=80=99s = that unsigned JWTs not be used on their own. Reference tokens and = encrypted JWTs are also valid, as are other signed formats like SAML = assertions or even a COSE Token (if it=E2=80=99s encoded to HTTP = friendliness).=20 >>>>>>>=20 >>>>>>> My recommendation: >>>>>>>=20 >>>>>>> Remove the erroneous requirement text from section 5 and restore = to previous version. >>>>>>>=20 >>>>>>> Amend the text in section 6 from: >>>>>>>=20 >>>>>>> To >>>>>>> simplify the subsequent description we assume in the PoP = architecture >>>>>>> that the token itself is digitally signed by the = authorization server >>>>>>> and therefore cannot be modified. >>>>>>>=20 >>>>>>>=20 >>>>>>> To: >>>>>>>=20 >>>>>>> In all such cases, the token remains opaque to the client. To >>>>>>> simplify the subsequent example and description we assume in = the PoP architecture >>>>>>> that the token itself cannot be modified by the client, = either due to >>>>>>> cryptographic protection (such as signature or encryption) or = use of=20 >>>>>>> a reference value with sufficient entropy and associated = secure lookup. >>>>>>> These are characteristics shared with bearer tokens and more = information >>>>>>> on best practices can be found in [[RFC6819]] and in the = security=20 >>>>>>> considerations section of [[RFC6750]].=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> =E2=80=94 Justin >>>>>>>=20 >>>>>>>> On Nov 25, 2015, at 3:39 PM, Kathleen Moriarty = > wrote: >>>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> Sent from my iPhone >>>>>>>>=20 >>>>>>>> On Nov 25, 2015, at 3:20 PM, John Bradley > wrote: >>>>>>>>=20 >>>>>>>>> Tokens are signed or the information is otherwise integrity = protected between the AS and the RS. =20 >>>>>>>>>=20 >>>>>>>>> I suspect Kathleen is concerned about the key getting modified = in transit. =20 >>>>>>>>> That needs to be protected against, but there is more than one = way to do that. >>>>>>>>=20 >>>>>>>> Phil is correct. I was looking for consistency between the = sections since they related to each other. If there is a security risk = or consideration, that needs to be explicitly called out as a concern = such as a key being modified in transit. If there are options to = protect against that, those would ideally be required or would have = warnings. >>>>>>>>>=20 >>>>>>>>> So sending the public key in a unsigned JWT access token would = be immensely stupid, not just for PoP but for scopes and everything = else. >>>>>>>>=20 >>>>>>>> Good, easy to require then. >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>> Kathleen=20 >>>>>>>>>=20 >>>>>>>>> In OAuth 2 all tokens need to be integrity protected between = the AS and RS. =20 >>>>>>>>> That can be via signature, by having a reference with = sufficient entropy and secure introspection or database lookup. >>>>>>>>>=20 >>>>>>>>> I think that is a OAuth 2 security consideration. We are = adding a additional confirmation claim to the existing information that = needs to be protected the same as the rest. >>>>>>>>>=20 >>>>>>>>> John B. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On Nov 25, 2015, at 4:38 PM, Phil Hunt > wrote: >>>>>>>>>>=20 >>>>>>>>>> >>>>>>>>>> If there is agreement that tokens are opaque then the = requirement that tokens be signed must be removed from the threat = mitigation requirements.=20 >>>>>>>>>>=20 >>>>>>>>>> And the paragraph in sec 5 that brian was concerned about be = restored.=20 >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>> On Nov 25, 2015, at 11:24, Justin Richer > wrote: >>>>>>>>>>=20 >>>>>>>>>>> It is still end to end authentication with opaque tokens =E2=80= =94 since all OAuth tokens, including PoP tokens, have always been = intended to be opaque to the client. That hasn=E2=80=99t changed and = that isn=E2=80=99t the intent of this document. If that=E2=80=99s how = people are reading it then we need to pull it back and rewrite it so = that=E2=80=99s not the case. >>>>>>>>>>>=20 >>>>>>>>>>> The client gets a token that has two parts: the token and = the key. The token is analogous to the access_token we have today and = would come out of the server in the same field. The key is handed to the = client alongside the token or registered by the client during the token = request. Either way there=E2=80=99s an association between the two but = it=E2=80=99s not the same association as a public/private keypair.=20 >>>>>>>>>>>=20 >>>>>>>>>>> It=E2=80=99s possible to sign the token itself, but the = client doesn=E2=80=99t care. It sends the token and signs the HTTP = request to the RS whether the token is signed, unsigned, hex blob, = encrypted, or anything else. The same series of options are available as = with bearer tokens. PoP tokens have never, ever been intended to be = anything but opaque to the client. >>>>>>>>>>>=20 >>>>>>>>>>> The token can=E2=80=99t be opaque to the RS, which has to = figure out what key to use to check the message signature. But we=E2=80=99= ve got options there, like the embedded key in a JWT from Mike=E2=80=99s = draft, or doing introspection to get the key (from an extension that = hasn=E2=80=99t been written yet), or simply looking it up in the same = database because the RS and the AS are in the same box. Does this = structure/service/database choice sound familiar? It should, it=E2=80=99s = the same as bearer tokens. This is also how the RS gets information like = which scopes are associated with the token, if it=E2=80=99s expired, and = all that.=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> So here=E2=80=99s how I see it going on the wire: >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> (I just wrote this up so there are probably holes. Here=E2=80=99= s the source if anyone wants to tweak it: = http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW50IGFzIEMKA= AwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3R= lY3RlZABICmFzIFJTCgoKClJPLS0 = -QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmV= jdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAK= QcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADA= FKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIA= E8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmN= sdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduY= XR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwB= iBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZ= CkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4= OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&= s=3Dmodern-blue ) >>>>>>>>>>>=20 >>>>>>>>>>> The client is oblivious to the token just like always. This = is intentional. The RS has the same options to figure out how to process = the token. >>>>>>>>>>>=20 >>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>=20 >>>>>>>>>>>> On Nov 25, 2015, at 2:03 PM, Phil Hunt = > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> Folks,=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> >>>>>>>>>>>> I did not want to go here either. :-) >>>>>>>>>>>>=20 >>>>>>>>>>>> I don=E2=80=99t read sec 6 as examples. I believe this may = stem from the pop-architecture documents having a dual role as both = =E2=80=9Carchitecture=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D. Maybe we = should clarify the purpose of the document? >>>>>>>>>>>>=20 >>>>>>>>>>>> I believe section 6 is talking about threat mitigation = assumptions based on the examples that need to be implemented. I am = assuming these are requirements that the other specifications SHOULD = implement. >>>>>>>>>>>>=20 >>>>>>>>>>>> >>>>>>>>>>>> I do not believe we have discussed Opaque PoP tokens and = any inherent risks because the client is not or is unable to validate = the authenticity of the token. Does this introduce the possibility of a = MITM attack where a client can be convinced to sign requests for an = attacker? >>>>>>>>>>>>=20 >>>>>>>>>>>> If we want to include opaque PoP, I think we need to take a = pause and consider / discuss any threats here. >>>>>>>>>>>>=20 >>>>>>>>>>>> I find the desire for opaque PoP tokens to be a bit = contradictory. If we=E2=80=99re saying we don=E2=80=99t want to trust = TLS alone (e.g. because of load-balancer termination), why would we then = say, but we are perfectly willing to accept it worked for the OAuth AS = exchanges? Maybe I was very wrong here, but my assumption all along is = that for PoP we=E2=80=99re talking about end-to-end authentication of = all parties except in the case of 3.3 where we simply want to protect an = access token over a non-TLS HTTP connection. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Phil >>>>>>>>>>>>=20 >>>>>>>>>>>> @independentid >>>>>>>>>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>>>>>>>>> On Nov 25, 2015, at 10:48 AM, Brian Campbell = > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> While I can't say I disagree with the deeper existential = questions about the draft that Justin raises, I was trying not to go = there and rather just point out concerns with the newly added text.=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The text Phil cites from Sec 6 doesn't say the client must = be able to parse and verify the token. It's an assumption to simplify = the examples that follow and still the token is opaque to the client. I = reread the whole draft (reluctantly) and there's nothing that says the = token has to be non-opaque to the client. And it does talk about = reference style tokens and encrypted tokens, both of which rely on the = opaqueness to the client.=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer = > wrote: >>>>>>>>>>>>> Right, I read that as text for describing the examples and = not for describing requirements. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The token itself doesn=E2=80=99t have to be signed at all. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Nov 25, 2015, at 1:05 PM, Phil Hunt = > wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Ok. Well this was requested by Kathleen because of this = paragraph in Sec 6.=E2=80=A6 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> To simplify the subsequent description we assume in = the PoP architecture >>>>>>>>>>>>>> that the token itself is digitally signed by the = authorization server >>>>>>>>>>>>>> and therefore cannot be modified. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Please=20 >>>>>>>>>>>>>> Phil >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> @independentid >>>>>>>>>>>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>>>>>>>>>>> On Nov 25, 2015, at 9:33 AM, Justin Richer = > wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The token doesn=E2=80=99t have to be signed and the = client doesn=E2=80=99t have to verify the signature on the token. = That=E2=80=99s not PoP. The request has to be signed in a way that = includes the token. The token itself can still be opaque. The *key* = material can=E2=80=99t be opaque to the client, but the *token* material = still is. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I agree with Brian that this statement is misleading. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The examples use a signed token but that is absolutely = not a requirement. Maybe the examples shouldn=E2=80=99t all use one = style. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> What=E2=80=99s most difficult about this particular spec = is that it=E2=80=99s very hand-wavy, saying =E2=80=9Cthis is kinda a = thing that kinda works like this=E2=80=9D without saying how to actually = do it. I=E2=80=99m honestly not sure it=E2=80=99s worth publishing as an = RFC in its own right but I=E2=80=99m not going to stand in its way. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Nov 25, 2015, at 12:14 PM, Brian Campbell = > wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Where does it say that?=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt = > wrote: >>>>>>>>>>>>>>>> Except that later on we require the token be signed and = the client verify that signed token. IOW mutual pop.=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Phil >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Nov 25, 2015, at 07:30, Brian Campbell = > wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Looking at the diff I noticed the following new text, = which seems to conflate bearer/PoP and opaqueness to the client. A = client demonstrating proof-of-possession of some key is orthogonal to = the client being able to parse and understand the access token itself.=20= >>>>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>>>> "In contrast to bearer tokens [RFC6750] which call for = tokens that are opaque to OAuth 2.0 clients, this specification defines = the requirements for proof-of-possession ("PoP") tokens that may be = parsed and verified by OAuth 2.0 clients and relying parties." >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt = > wrote: >>>>>>>>>>>>>>>>> This draft addresses review comments from Kathleen and = Erik raised since the last draft. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> It may not include some of the discussion from = yesterday/today. I will add that as the group decides. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Phil >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> @independentid >>>>>>>>>>>>>>>>> www.independentid.com >>>>>>>>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> > On Nov 24, 2015, at 12:05 PM, = internet-drafts@ietf.org wrote: >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>>>>>>>>>>>> > This draft is a work item of the Web Authorization = Protocol Working Group of the IETF. >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > Title : OAuth 2.0 = Proof-of-Possession (PoP) Security Architecture >>>>>>>>>>>>>>>>> > Authors : Phil Hunt >>>>>>>>>>>>>>>>> > Justin Richer >>>>>>>>>>>>>>>>> > William Mills >>>>>>>>>>>>>>>>> > Prateek Mishra >>>>>>>>>>>>>>>>> > Hannes Tschofenig >>>>>>>>>>>>>>>>> > Filename : = draft-ietf-oauth-pop-architecture-06.txt >>>>>>>>>>>>>>>>> > Pages : 23 >>>>>>>>>>>>>>>>> > Date : 2015-11-24 >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > 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 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. >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > The IETF datatracker status page for this draft is: >>>>>>>>>>>>>>>>> > = https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ = >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > There's also a htmlized version available at: >>>>>>>>>>>>>>>>> > = https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 = >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > A diff from the previous version is available at: >>>>>>>>>>>>>>>>> > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 = = >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > 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 . >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > Internet-Drafts are also available by anonymous FTP = at: >>>>>>>>>>>>>>>>> > ftp://ftp.ietf.org/internet-drafts/ = >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>>>>>>> > OAuth mailing list >>>>>>>>>>>>>>>>> > OAuth@ietf.org >>>>>>>>>>>>>>>>> > https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>>>>> =09= >>>>>>>>>>>>>>>>> Brian Campbell >>>>>>>>>>>>>>>>> Distinguished Engineer >>>>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>>>>>>>> @pingidentity >>>>>>>>>>>>>>>>> Connect with us! >>>>>>>>>>>>>>>>> = >>>>>>>>>>>>>>>>> = = = = = = = = = >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>>>> =09= >>>>>>>>>>>>>>>> Brian Campbell >>>>>>>>>>>>>>>> Distinguished Engineer >>>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>>>>>>> @pingidentity >>>>>>>>>>>>>>>> Connect with us! >>>>>>>>>>>>>>>> = >>>>>>>>>>>>>>>> = = = = = = = = = _____________________________________= __________ >>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> --=20 >>>>>>>>>>>>> =09 >>>>>>>>>>>>> Brian Campbell >>>>>>>>>>>>> Distinguished Engineer >>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>>>> @pingidentity >>>>>>>>>>>>> Connect with us! >>>>>>>>>>>>> = >>>>>>>>>>>>> = = = = = = = = = >>>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>>=20 >>>>>> Best regards, >>>>>> Kathleen >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>>=20 >>>> Best regards, >>>> Kathleen >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_60C1A29F-3730-40D6-9C13-48FEA051CAFC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That looks good to me.

On = Dec 1, 2015, at 4:21 PM, Justin Richer <jricher@mit.edu> = wrote:

You=E2=80=99ve = got =E2=80=9CThe token remains opaque to the client=E2=80=9D in there = twice now. I had cut out the middle part the first sentence in the = second paragraph below, but that was hard to highlight. If you take my = text as-is that=E2=80=99s what I meant for the edited form.

Thanks
 =E2=80=94 Justin

On Dec = 1, 2015, at 2:18 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Including = Justin=E2=80=99s revision:

  A large range of threats can be mitigated by protecting the =
content
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).

   To simplify discussion in the following examples, we assume that the
   token itself is integrity protected by the authorization server and
   the token remains opaque to the client.  The token itself cannot be
   modified by the client, either due to cryptographic protection (such
   as signature or encryption) or the use of a reference value with
   sufficient entropy and associated secure lookup.  The token remains
   opaque to the client.  These are characteristics shared with bearer
   tokens and more information on best practices can be found in
   [RFC6819] and in the security considerations section of [RFC6750].


On Dec 1, 2015, at 10:35 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Thanks Justin. Your = tweaks look good to me.


On Dec 1, 2015, at 10:28 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

The changes work for me, thanks.

On Tue, = Dec 1, 2015 at 1:27 PM, Justin Richer <jricher@mit.edu> wrote:
That=E2=80=99s much better. I would also suggest that a few = edits to hammer home that this is an example

 A large range of threats can =
be mitigated by protecting the content
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).  To
   simplify discussion=
 in the following example we assume=20
   that the token itself [=E2=80=A6]
   cannot be modified by the client, either due to cryptographic
   protection (such as signature or encryption) or use of a reference
   value with sufficient entropy and associated secure lookup.  =
The token remains =
opaque to the client.
These
   are characteristics shared with bearer tokens and more information on
   best practices can be found in [RFC6819] and in the security
   considerations section of =
[RFC6750].

That=E2=80=99s really what=E2=80=99s going on by my read. = Thoughts?

 =E2=80= =94 Justin

On Dec 1, 2015, at 1:08 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

I=E2=80=99ve reviewed the = comments from John, Justin and Kathleen. As suggested, I plan to remove = the erroneous first paragraph in section 5 (draft 06).

Combining the comments from this thread = about sec 6, here is the proposed new first paragraph:

 A large =
range of threats can be mitigated by protecting the content
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).  To
   simplify the subsequent description we assume in the PoP architecture
   that the token itself is integrity protected by the authorization
   server and the token remains opaque to the client.  The token itself
   cannot be modified by the client, either due to cryptographic
   protection (such as signature or encryption) or use of a reference
   value with sufficient entropy and associated secure lookup.  These
   are characteristics shared with bearer tokens and more information on
   best practices can be found in [RFC6819] and in the security
   considerations section of [RFC6750].
If this = looks good to the group, I=E2=80=99ll post draft 7 this afternoon = (pacific).

Thanks,


On Nov 25, 2015, at 2:19 PM, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> wrote:



On Wed, = Nov 25, 2015 at 3:58 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I am fine with that, however = saying integrity protected, may be better than signed.  May people = will argue that HMAC or encryption with sender verification is not = signature.

Good point, I also prefer integrity protected.  Are we = all good with this now?  I'd like to look at a diff to make sure = after following the thread.

Thanks!
Kathleen
 
However they are perfectly valid.


On Nov 25, 2015, at 5:53 PM, Justin Richer = <jricher@mit.edu> wrote:

The = requirement is not that signed JWTs be used, it=E2=80=99s that unsigned = JWTs not be used on their own. Reference tokens and encrypted JWTs are = also valid, as are other signed formats like SAML assertions or even a = COSE Token (if it=E2=80=99s encoded to HTTP friendliness). 

My = recommendation:

Remove the erroneous requirement text from section 5 and = restore to previous version.

Amend the text in section 6 = from:

   To
   simplify the subsequent description we assume in the PoP architecture

   that the token itself is digitally signed by =
the authorization server
   and therefore cannot be modified.


To:

   In all such cases, the token remains =
opaque to the client. To
   simplify the subsequent example and description we assume in the PoP =
architecture
   that the token itself cannot be =
modified by the client, either due to
   =
cryptographic protection (such as signature or encryption) or use =
of 
   a reference value with sufficient =
entropy and associated secure lookup.
   These are =
characteristics shared with bearer tokens and more information
   on best practices can be found in [[RFC6819]] and in the =
security 
   considerations section of =
[[RFC6750]].


 =E2=80=94 = Justin

On Nov 25, 2015, at 3:39 PM, = Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> = wrote:

Hi,

Sent from my iPhone

On = Nov 25, 2015, at 3:20 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Tokens are signed or the information is otherwise integrity = protected between the AS and the RS.  

I suspect Kathleen is concerned about = the key getting modified in transit.   
That needs to be protected against, but there is more than = one way to do that.

Phil is correct.  I was looking for consistency = between the sections since they related to each other.  If there is = a security risk or consideration, that needs to be explicitly called out = as a concern such as a key being modified in transit.  If there are = options to protect against that, those would ideally be required or = would have warnings.

So sending the public key in a unsigned JWT access token = would be immensely stupid,  not just for PoP but for scopes and = everything else.

Good, easy to require then.

Thanks,
Kathleen 

In OAuth 2 all tokens need to be integrity protected between = the AS and RS.  
That can be via signature, =  by having a reference with sufficient entropy and secure = introspection or database lookup.

I think that is a OAuth 2 security = consideration.   We are adding a additional confirmation claim to = the existing information that needs to be protected the same as the = rest.

John = B.


On Nov 25, 2015, at 4:38 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

<editors = hat>
If there is agreement that tokens are = opaque then the requirement that tokens be signed must be removed from = the threat mitigation requirements. 

And the paragraph in sec 5 that brian = was concerned about be restored. 

Phil

On Nov 25, 2015, at 11:24, Justin Richer <jricher@mit.edu> wrote:

It = is still end to end authentication with opaque tokens =E2=80=94 since = all OAuth tokens, including PoP tokens, have always been intended to be = opaque to the client. That hasn=E2=80=99t changed and that isn=E2=80=99t = the intent of this document. If that=E2=80=99s how people are reading it = then we need to pull it back and rewrite it so that=E2=80=99s not the = case.

The client = gets a token that has two parts: the token and the key. The token is = analogous to the access_token we have today and would come out of the = server in the same field. The key is handed to the client alongside the = token or registered by the client during the token request. Either way = there=E2=80=99s an association between the two but it=E2=80=99s not the = same association as a public/private keypair. 

It=E2=80=99s possible to = sign the token itself, but the client doesn=E2=80=99t care. It sends the = token and signs the HTTP request to the RS whether the token is signed, = unsigned, hex blob, encrypted, or anything else. The same series of = options are available as with bearer tokens. PoP tokens have never, ever = been intended to be anything but opaque to the client.

The token can=E2=80=99t = be opaque to the RS, which has to figure out what key to use to check = the message signature. But we=E2=80=99ve got options there, like the = embedded key in a JWT from Mike=E2=80=99s draft, or doing introspection = to get the key (from an extension that hasn=E2=80=99t been written yet), = or simply looking it up in the same database because the RS and the AS = are in the same box. Does this structure/service/database choice sound = familiar? It should, it=E2=80=99s the same as bearer tokens. This is = also how the RS gets information like which scopes are associated with = the token, if it=E2=80=99s expired, and all that. 




So here=E2=80=99s how I see it going on the wire:



3D"http://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DcGFydGljaXBhb=



(I just wrote this up so = there are probably holes. Here=E2=80=99s the source if anyone wants to = tweak it: http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW= 50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZB= UwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPl= JPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAV= BwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcm= VxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsA= EAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUz= ogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVj= awCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludH= Jvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGlj= IG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAI= QoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiBy= ZXR1cm4AhicJ&s=3Dmodern-blue )

The client is oblivious to the token = just like always. This is intentional. The RS has the same options to = figure out how to process the token.

 =E2=80=94 Justin

On Nov 25, 2015, at 2:03 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Folks, 

<editor = hat>
I did not want to go here either. = :-)

I don=E2=80=99= t read sec 6 as examples.  I believe this may stem from the = pop-architecture documents having a dual role as both =E2=80=9Carchitectur= e=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D.  Maybe we should clarify = the purpose of the document?

I believe section 6 is talking about = threat mitigation assumptions based on the examples that need to be = implemented.  I am assuming these are requirements that the other = specifications SHOULD implement.

<personal hat>
I do not believe we have discussed Opaque PoP tokens and any = inherent risks because the client is not or is unable to validate the = authenticity of the token.  Does this introduce the possibility of = a MITM attack where a client can be convinced to sign requests for an = attacker?

If = we want to include opaque PoP, I think we need to take a pause and = consider / discuss any threats here.

I find the desire for opaque PoP tokens = to be a bit contradictory. If we=E2=80=99re saying we don=E2=80=99t want = to trust TLS alone (e.g. because of load-balancer termination), why = would we then say, but we are perfectly willing to accept it worked for = the OAuth AS exchanges?  Maybe I was very wrong here, but my = assumption all along is that for PoP we=E2=80=99re talking about = end-to-end authentication of all parties except in the case of 3.3 where = we simply want to protect an access token over a non-TLS HTTP = connection.



On Nov 25, 2015, at 10:48 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

While I can't say I disagree with the deeper = existential questions about the draft that Justin raises, I was trying = not to go there and rather just point out concerns with the newly added = text.

The text Phil cites from Sec 6 = doesn't say the client must be able to parse and verify the token. It's = an assumption to simplify the examples that follow and still the token = is opaque to the client. I reread the whole draft (reluctantly) and = there's nothing that says the token has to be non-opaque to the client. = And it does talk about reference style tokens and encrypted tokens, both = of which rely on the opaqueness to the client.

On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer = <jricher@mit.edu> wrote:
Right, I read that as text for = describing the examples and not for describing requirements.

The token itself = doesn=E2=80=99t have to be signed at all.

 =E2=80=94 Justin

On Nov 25, 2015, at 1:05 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:

Ok. Well this was = requested by Kathleen because of this paragraph in Sec 6.=E2=80=A6

   =
To simplify the subsequent description we assume in the PoP =
architecture
   =
that the token itself is digitally signed by the authorization server

   and therefore cannot be modified.

Please 

On Nov 25, 2015, at 9:33 AM, Justin Richer <jricher@mit.edu> wrote:

The token = doesn=E2=80=99t have to be signed and the client doesn=E2=80=99t have to = verify the signature on the token. That=E2=80=99s not PoP. The request = has to be signed in a way that includes the token. The token itself can = still be opaque. The *key* material can=E2=80=99t be opaque to the = client, but the *token* material still is.

I agree with Brian that this statement = is misleading.

The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one = style.

What=E2=80= =99s most difficult about this particular spec is that it=E2=80=99s very = hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda works like = this=E2=80=9D without saying how to actually do it. I=E2=80=99m honestly = not sure it=E2=80=99s worth publishing as an RFC in its own right but = I=E2=80=99m not going to stand in its way.

 =E2=80=94 Justin

On Nov 25, 2015, at 12:14 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

Where does it say = that?



On Wed, = Nov 25, 2015 at 8:44 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Except that later on we require the token be = signed and the client verify that signed token. IOW mutual = pop. 

Phil

On Nov 25, 2015, at 07:30, = Brian Campbell <bcampbell@pingidentity.com> = wrote:

Looking at the = diff I noticed the following new text, which seems to conflate = bearer/PoP and opaqueness to the client. A client demonstrating = proof-of-possession of some key is orthogonal to the client being able = to parse and understand the access token itself.
 
"In contrast to bearer tokens [RFC6750] which call for tokens = that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
This draft = addresses review comments from Kathleen and Erik raised since the last = draft.

It may not include some of the discussion from yesterday/today.  I = will add that as the group decides.

Cheers,

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF.
>
>        Title          =  : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors        =  : Phil Hunt
>                  =         Justin Richer
>                  =         William Mills
>                  =         Prateek Mishra
>                  =         Hannes Tschofenig
>       Filename        : = draft-ietf-oauth-pop-architecture-06.txt
>       Pages          =  : 23
>       Date          =   : 2015-11-24
>
> 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 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.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth






--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


________________________________= _______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
________________________________= _______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





--

Best regards,
Kathleen
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--

Best regards,
Kathleen

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_60C1A29F-3730-40D6-9C13-48FEA051CAFC-- From nobody Tue Dec 1 15:10:10 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78011B29AB for ; Tue, 1 Dec 2015 15:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKrkWvCYWbQc for ; Tue, 1 Dec 2015 15:10:02 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924E51ADBFA for ; Tue, 1 Dec 2015 15:09:44 -0800 (PST) Received: by wmww144 with SMTP id w144so34147491wmw.0 for ; Tue, 01 Dec 2015 15:09:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oyTmnXmpWaGaxuZ1O7ozq7o6Bv3RTPjReJHx1lYv5MY=; b=zxQ8irCFMTZr1ujS7GAMvfywpR44PfzYpXaiQ/XL4+cIC8Hc2oCNuqnWAlVfnjcCEy /JAx42TwMJTj2ZAvllTqmUjrY0AsyZaLRhOVbEjpZlfS8Nbi9kRFx0dkdAqg6yWuBpP/ iQiZa8tpjDEBGW/injqNCEzHGzgM3lLXJFvPMS9tDNOFYh0ftCQDNGBe5uwv3VqpVVXB Mj374r7Xc8gbihLYiayop+cWuHPJ2RZgVTZn4iMlf1sLqUa0Q6y7LpLOyrsGEzeDVV9r jmwRKS/1R3Mk5MnUk9Y1JrWVapxmTULsOXOIo2b1aGJvJElsE7474gXbXhGnnUPeTnge x0Bw== MIME-Version: 1.0 X-Received: by 10.28.218.17 with SMTP id r17mr1008003wmg.90.1449011382934; Tue, 01 Dec 2015 15:09:42 -0800 (PST) Received: by 10.28.52.130 with HTTP; Tue, 1 Dec 2015 15:09:42 -0800 (PST) In-Reply-To: References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> <1AD1F44B-9837-4288-9997-5292F1DBE30E@oracle.com> <9E20E73C-AC35-4E03-A011-119A32CD0BF1@ve7jtb.com> <7431079B-818C-46E9-8102-D193E49384B2@gmail.com> <638FA321-4DE1-467C-9B5C-3BEA0EC3EB0F@mit.edu> <207E620F-97AA-4851-8776-2A7B1921D58A@ve7jtb.com> <9F9526D9-A32A-4E34-A54D-8CC47A15E862@oracle.com> <6636599A-B628-4ABE-88A9-911219501096@oracle.com> Date: Tue, 1 Dec 2015 18:09:42 -0500 Message-ID: From: Kathleen Moriarty To: John Bradley Content-Type: multipart/alternative; boundary=001a1145b64ec1647a0525de40e8 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 23:10:10 -0000 --001a1145b64ec1647a0525de40e8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, guys. If we are all okay, I'll start the last call once the new draft is posted. I need to get them started by sometime tomorrow to keep them on the telechat in 2 weeks. Thanks, Kathleen On Tue, Dec 1, 2015 at 5:28 PM, John Bradley wrote: > That looks good to me. > > On Dec 1, 2015, at 4:21 PM, Justin Richer wrote: > > You=E2=80=99ve got =E2=80=9CThe token remains opaque to the client=E2=80= =9D in there twice now. I > had cut out the middle part the first sentence in the second paragraph > below, but that was hard to highlight. If you take my text as-is that=E2= =80=99s > what I meant for the edited form. > > Thanks > =E2=80=94 Justin > > On Dec 1, 2015, at 2:18 PM, Phil Hunt wrote: > > Including Justin=E2=80=99s revision: > > A large range of threats can be mitigated by protecting the content > of the token, for example using a digital signature or a keyed > message digest. Alternatively, the content of the token could be > passed by reference rather than by value (requiring a separate > message exchange to resolve the reference to the token content). > > To simplify discussion in the following examples, we assume that the > token itself is integrity protected by the authorization server and > the token remains opaque to the client. The token itself cannot be > modified by the client, either due to cryptographic protection (such > as signature or encryption) or the use of a reference value with > sufficient entropy and associated secure lookup. The token remains > opaque to the client. These are characteristics shared with bearer > tokens and more information on best practices can be found in > [RFC6819] and in the security considerations section of [RFC6750]. > > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Dec 1, 2015, at 10:35 AM, Phil Hunt wrote: > > Thanks Justin. Your tweaks look good to me. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Dec 1, 2015, at 10:28 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > The changes work for me, thanks. > > On Tue, Dec 1, 2015 at 1:27 PM, Justin Richer wrote: > >> That=E2=80=99s much better. I would also suggest that a few edits to ham= mer home >> that this is an example >> >> A large range of threats can be mitigated by protecting the content >> of the token, for example using a digital signature or a keyed >> message digest. Alternatively, the content of the token could be >> passed by reference rather than by value (requiring a separate >> message exchange to resolve the reference to the token content). To >> simplify *discussion in the following example* we assume >> that the token itself *[=E2=80=A6**]* >> cannot be modified by the client, either due to cryptographic >> protection (such as signature or encryption) or use of a reference >> value with sufficient entropy and associated secure lookup. *The tok= en remains opaque to the client.* >> >> These >> are characteristics shared with bearer tokens and more information on >> best practices can be found in [RFC6819] and in the security >> considerations section of [RFC6750]. >> >> >> That=E2=80=99s really what=E2=80=99s going on by my read. Thoughts? >> >> =E2=80=94 Justin >> >> On Dec 1, 2015, at 1:08 PM, Phil Hunt wrote: >> >> I=E2=80=99ve reviewed the comments from John, Justin and Kathleen. As su= ggested, >> I plan to remove the erroneous first paragraph in section 5 (draft 06). >> >> Combining the comments from this thread about sec 6, here is the propose= d >> new first paragraph: >> >> A large range of threats can be mitigated by protecting the content >> of the token, for example using a digital signature or a keyed >> message digest. Alternatively, the content of the token could be >> passed by reference rather than by value (requiring a separate >> message exchange to resolve the reference to the token content). To >> simplify the subsequent description we assume in the PoP architecture >> that the token itself is integrity protected by the authorization >> server and the token remains opaque to the client. The token itself >> cannot be modified by the client, either due to cryptographic >> protection (such as signature or encryption) or use of a reference >> value with sufficient entropy and associated secure lookup. These >> are characteristics shared with bearer tokens and more information on >> best practices can be found in [RFC6819] and in the security >> considerations section of [RFC6750]. >> >> If this looks good to the group, I=E2=80=99ll post draft 7 this afternoo= n >> (pacific). >> >> Thanks, >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> On Nov 25, 2015, at 2:19 PM, Kathleen Moriarty < >> Kathleen.Moriarty.ietf@gmail.com> wrote: >> >> >> >> On Wed, Nov 25, 2015 at 3:58 PM, John Bradley wrote: >> >>> I am fine with that, however saying integrity protected, may be better >>> than signed. May people will argue that HMAC or encryption with sender >>> verification is not signature. >>> >> >> Good point, I also prefer integrity protected. Are we all good with thi= s >> now? I'd like to look at a diff to make sure after following the thread= . >> >> Thanks! >> Kathleen >> >> >> >>> However they are perfectly valid. >>> >>> >>> On Nov 25, 2015, at 5:53 PM, Justin Richer wrote: >>> >>> The requirement is not that signed JWTs be used, it=E2=80=99s that unsi= gned JWTs >>> not be used on their own. Reference tokens and encrypted JWTs are also >>> valid, as are other signed formats like SAML assertions or even a COSE >>> Token (if it=E2=80=99s encoded to HTTP friendliness). >>> >>> My recommendation: >>> >>> Remove the erroneous requirement text from section 5 and restore to >>> previous version. >>> >>> Amend the text in section 6 from: >>> >>> To >>> simplify the subsequent description we assume in the PoP architectur= e >>> >>> that the token itself is digitally signed by the authorization serve= r >>> and therefore cannot be modified. >>> >>> >>> >>> To: >>> >>> In all such cases, the token remains opaque to the client. To >>> simplify the subsequent example and description we assume in the PoP= architecture >>> >>> that the token itself cannot be modified by the client, either due t= o >>> >>> cryptographic protection (such as signature or encryption) or use of >>> >>> a reference value with sufficient entropy and associated secure look= up. >>> >>> These are characteristics shared with bearer tokens and more informa= tion >>> >>> on best practices can be found in [[RFC6819]] and in the security >>> >>> considerations section of [[RFC6750]]. >>> >>> >>> >>> =E2=80=94 Justin >>> >>> On Nov 25, 2015, at 3:39 PM, Kathleen Moriarty < >>> kathleen.moriarty.ietf@gmail.com> wrote: >>> >>> Hi, >>> >>> Sent from my iPhone >>> >>> On Nov 25, 2015, at 3:20 PM, John Bradley wrote: >>> >>> Tokens are signed or the information is otherwise integrity protected >>> between the AS and the RS. >>> >>> I suspect Kathleen is concerned about the key getting modified in >>> transit. >>> That needs to be protected against, but there is more than one way to d= o >>> that. >>> >>> >>> Phil is correct. I was looking for consistency between the sections >>> since they related to each other. If there is a security risk or >>> consideration, that needs to be explicitly called out as a concern such= as >>> a key being modified in transit. If there are options to protect again= st >>> that, those would ideally be required or would have warnings. >>> >>> >>> So sending the public key in a unsigned JWT access token would be >>> immensely stupid, not just for PoP but for scopes and everything else. >>> >>> >>> Good, easy to require then. >>> >>> Thanks, >>> Kathleen >>> >>> >>> In OAuth 2 all tokens need to be integrity protected between the AS and >>> RS. >>> That can be via signature, by having a reference with sufficient >>> entropy and secure introspection or database lookup. >>> >>> I think that is a OAuth 2 security consideration. We are adding a >>> additional confirmation claim to the existing information that needs to= be >>> protected the same as the rest. >>> >>> John B. >>> >>> >>> On Nov 25, 2015, at 4:38 PM, Phil Hunt wrote: >>> >>> >>> If there is agreement that tokens are opaque then the requirement that >>> tokens be signed must be removed from the threat mitigation requirement= s. >>> >>> And the paragraph in sec 5 that brian was concerned about be restored. >>> >>> Phil >>> >>> On Nov 25, 2015, at 11:24, Justin Richer wrote: >>> >>> It is still end to end authentication with opaque tokens =E2=80=94 sinc= e all >>> OAuth tokens, including PoP tokens, have always been intended to be opa= que >>> to the client. That hasn=E2=80=99t changed and that isn=E2=80=99t the i= ntent of this >>> document. If that=E2=80=99s how people are reading it then we need to p= ull it back >>> and rewrite it so that=E2=80=99s not the case. >>> >>> The client gets a token that has two parts: the token and the key. The >>> token is analogous to the access_token we have today and would come out= of >>> the server in the same field. The key is handed to the client alongside= the >>> token or registered by the client during the token request. Either way >>> there=E2=80=99s an association between the two but it=E2=80=99s not the= same association as >>> a public/private keypair. >>> >>> It=E2=80=99s possible to sign the token itself, but the client doesn=E2= =80=99t care. It >>> sends the token and signs the HTTP request to the RS whether the token = is >>> signed, unsigned, hex blob, encrypted, or anything else. The same serie= s of >>> options are available as with bearer tokens. PoP tokens have never, eve= r >>> been intended to be anything but opaque to the client. >>> >>> The token can=E2=80=99t be opaque to the RS, which has to figure out wh= at key to >>> use to check the message signature. But we=E2=80=99ve got options there= , like the >>> embedded key in a JWT from Mike=E2=80=99s draft, or doing introspection= to get the >>> key (from an extension that hasn=E2=80=99t been written yet), or simply= looking it >>> up in the same database because the RS and the AS are in the same box. = Does >>> this structure/service/database choice sound familiar? It should, it=E2= =80=99s the >>> same as bearer tokens. This is also how the RS gets information like wh= ich >>> scopes are associated with the token, if it=E2=80=99s expired, and all = that. >>> >>> >>> >>> >>> So here=E2=80=99s how I see it going on the wire: >>> >>> >>> >>> [image: >>> http://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DcGFydGljaXBhbnQgQ= 2xpZW50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYA= IQZBUwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPlJ= POiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBw= BrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxd= WVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtl= bHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgC= BUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAA= dzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY= 3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNo= YXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAU= AgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4Ahi= cJ&s=3Dmodern-blue] >>> >>> >>> >>> (I just wrote this up so there are probably holes. Here=E2=80=99s the s= ource if >>> anyone wants to tweak it: >>> http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW50IGFzIE= MKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb= 3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmVj= dCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAKQc= APAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADAFKQ= pBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIAE8pI= CYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmNsdWRp= bmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduYXR1cmU= gLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwBiBkFTOi= BzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZCkAgwIGZ= GF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4OAIQsCACC= BAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&s=3Dmodern= -blue >>> ) >>> >>> The client is oblivious to the token just like always. This is >>> intentional. The RS has the same options to figure out how to process t= he >>> token. >>> >>> =E2=80=94 Justin >>> >>> On Nov 25, 2015, at 2:03 PM, Phil Hunt wrote: >>> >>> Folks, >>> >>> >>> I did not want to go here either. :-) >>> >>> I don=E2=80=99t read sec 6 as examples. I believe this may stem from t= he >>> pop-architecture documents having a dual role as both =E2=80=9Carchitec= ture=E2=80=9D and >>> =E2=80=9Cuse-case=E2=80=9D. Maybe we should clarify the purpose of the= document? >>> >>> I believe section 6 is talking about threat mitigation assumptions base= d >>> on the examples that need to be implemented. I am assuming these are >>> requirements that the other specifications SHOULD implement. >>> >>> >>> I do not believe we have discussed Opaque PoP tokens and any inherent >>> risks because the client is not or is unable to validate the authentici= ty >>> of the token. Does this introduce the possibility of a MITM attack whe= re a >>> client can be convinced to sign requests for an attacker? >>> >>> If we want to include opaque PoP, I think we need to take a pause and >>> consider / discuss any threats here. >>> >>> I find the desire for opaque PoP tokens to be a bit contradictory. If >>> we=E2=80=99re saying we don=E2=80=99t want to trust TLS alone (e.g. bec= ause of >>> load-balancer termination), why would we then say, but we are perfectly >>> willing to accept it worked for the OAuth AS exchanges? Maybe I was ve= ry >>> wrong here, but my assumption all along is that for PoP we=E2=80=99re t= alking about >>> end-to-end authentication of all parties except in the case of 3.3 wher= e we >>> simply want to protect an access token over a non-TLS HTTP connection. >>> >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> On Nov 25, 2015, at 10:48 AM, Brian Campbell >>> wrote: >>> >>> While I can't say I disagree with the deeper existential questions abou= t >>> the draft that Justin raises, I was trying not to go there and rather j= ust >>> point out concerns with the newly added text. >>> >>> The text Phil cites from Sec 6 doesn't say the client must be able to >>> parse and verify the token. It's an assumption to simplify the examples >>> that follow and still the token is opaque to the client. I reread the w= hole >>> draft (reluctantly) and there's nothing that says the token has to be >>> non-opaque to the client. And it does talk about reference style tokens= and >>> encrypted tokens, both of which rely on the opaqueness to the client. >>> >>> On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer wrote= : >>> >>>> Right, I read that as text for describing the examples and not for >>>> describing requirements. >>>> >>>> The token itself doesn=E2=80=99t have to be signed at all. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Nov 25, 2015, at 1:05 PM, Phil Hunt wrote: >>>> >>>> Ok. Well this was requested by Kathleen because of this paragraph in >>>> Sec 6.=E2=80=A6 >>>> >>>> >>>> To simplify the subsequent description we assume in the PoP archite= cture >>>> >>>> that the token itself is digitally signed by the authorization serv= er >>>> >>>> and therefore cannot be modified. >>>> >>>> >>>> Please >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>> >>>> On Nov 25, 2015, at 9:33 AM, Justin Richer wrote: >>>> >>>> The token doesn=E2=80=99t have to be signed and the client doesn=E2=80= =99t have to >>>> verify the signature on the token. That=E2=80=99s not PoP. The request= has to be >>>> signed in a way that includes the token. The token itself can still be >>>> opaque. The *key* material can=E2=80=99t be opaque to the client, but = the *token* >>>> material still is. >>>> >>>> I agree with Brian that this statement is misleading. >>>> >>>> The examples use a signed token but that is absolutely not a >>>> requirement. Maybe the examples shouldn=E2=80=99t all use one style. >>>> >>>> What=E2=80=99s most difficult about this particular spec is that it=E2= =80=99s very >>>> hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda works like= this=E2=80=9D >>>> without saying how to actually do it. I=E2=80=99m honestly not sure it= =E2=80=99s worth >>>> publishing as an RFC in its own right but I=E2=80=99m not going to sta= nd in its way. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Nov 25, 2015, at 12:14 PM, Brian Campbell < >>>> bcampbell@pingidentity.com> wrote: >>>> >>>> Where does it say that? >>>> >>>> >>>> >>>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt >>>> wrote: >>>> >>>>> Except that later on we require the token be signed and the client >>>>> verify that signed token. IOW mutual pop. >>>>> >>>>> Phil >>>>> >>>>> On Nov 25, 2015, at 07:30, Brian Campbell >>>>> wrote: >>>>> >>>>> Looking at the diff I noticed the following new text, which seems to >>>>> conflate bearer/PoP and opaqueness to the client. A client demonstrat= ing >>>>> proof-of-possession of some key is orthogonal to the client being abl= e to >>>>> parse and understand the access token itself. >>>>> >>>>> "In contrast to bearer tokens [RFC6750] which call for tokens that ar= e >>>>> opaque to OAuth 2.0 clients, this specification defines the requireme= nts >>>>> for proof-of-possession ("PoP") tokens that may be parsed and verifie= d by >>>>> OAuth 2.0 clients and relying parties." >>>>> >>>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt >>>>> wrote: >>>>> >>>>>> This draft addresses review comments from Kathleen and Erik raised >>>>>> since the last draft. >>>>>> >>>>>> It may not include some of the discussion from yesterday/today. I >>>>>> will add that as the group decides. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Phil >>>>>> >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>> >>>>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote: >>>>>> > >>>>>> > >>>>>> > A New Internet-Draft is available from the on-line Internet-Drafts >>>>>> directories. >>>>>> > This draft is a work item of the Web Authorization Protocol Workin= g >>>>>> Group of the IETF. >>>>>> > >>>>>> > Title : OAuth 2.0 Proof-of-Possession (PoP) >>>>>> Security Architecture >>>>>> > Authors : Phil Hunt >>>>>> > Justin Richer >>>>>> > William Mills >>>>>> > Prateek Mishra >>>>>> > Hannes Tschofenig >>>>>> > Filename : draft-ietf-oauth-pop-architecture-06.txt >>>>>> > Pages : 23 >>>>>> > Date : 2015-11-24 >>>>>> > >>>>>> > 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 = 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. >>>>>> > >>>>>> > >>>>>> > The IETF datatracker status page for this draft is: >>>>>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture= / >>>>>> > >>>>>> > There's also a htmlized version available at: >>>>>> > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 >>>>>> > >>>>>> > A diff from the previous version is available at: >>>>>> > >>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architectur= e-06 >>>>>> > >>>>>> > >>>>>> > 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.or= g >>>>>> . >>>>>> > >>>>>> > Internet-Drafts are also available by anonymous FTP at: >>>>>> > ftp://ftp.ietf.org/internet-drafts/ >>>>>> > >>>>>> > _______________________________________________ >>>>>> > OAuth mailing list >>>>>> > OAuth@ietf.org >>>>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> [image: Ping Identity logo] >>>>> Brian Campbell >>>>> Distinguished Engineer >>>>> Ping Identity >>>>> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 [image: >>>>> twitter] @pingidentity Connect with us! >>>>> [image: pingidentity.com] >>>>> >>>>> [image: >>>>> pingidentity.com] >>>>> >>>>> [image: twitter logo] >>>>> [image: >>>>> twitter logo] [image: youtube logo= ] >>>>> [image: LinkedIn logo] >>>>> [image: Facebook logo] >>>>> [image: Google+ logo] >>>>> [image: >>>>> slideshare logo] [image: >>>>> flipboard logo] [image: rss feed icon] >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> [image: Ping Identity logo] >>>> Brian Campbell >>>> Distinguished Engineer >>>> Ping Identity >>>> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 [image: >>>> twitter] @pingidentity Connect with us! >>>> [image: pingidentity.com] >>>> >>>> [image: >>>> pingidentity.com] >>>> >>>> [image: twitter logo] >>>> [image: >>>> twitter logo] [image: youtube logo] >>>> [image: LinkedIn logo] >>>> [image: Facebook logo] >>>> [image: Google+ logo] >>>> [image: slideshare >>>> logo] [image: flipboard logo] >>>> [image: rss feed icon] >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> [image: Ping Identity logo] >>> Brian Campbell >>> Distinguished Engineer >>> Ping Identity >>> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 [image: >>> twitter] @pingidentity Connect with us! >>> [image: pingidentity.com] >>> >>> [image: >>> pingidentity.com] >>> >>> [image: twitter logo] >>> [image: >>> twitter logo] [image: youtube logo] >>> [image: LinkedIn logo] >>> [image: Facebook logo] >>> [image: Google+ logo] >>> [image: slideshare >>> logo] [image: flipboard logo] >>> [image: rss feed icon] >>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >> >> >> -- >> >> Best regards, >> Kathleen >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > > > -- > > Best regards, > Kathleen > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Best regards, Kathleen --001a1145b64ec1647a0525de40e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, guys.=C2=A0 If we are all okay, I'll start the= last call once the new draft is posted.=C2=A0 I need to get them started b= y sometime tomorrow to keep them on the telechat in 2 weeks.

=
Thanks,
Kathleen

<= div class=3D"gmail_quote">On Tue, Dec 1, 2015 at 5:28 PM, John Bradley <ve= 7jtb@ve7jtb.com> wrote:
That looks good to me.

On Dec 1, 2015, at 4:21 PM,= Justin Richer <jri= cher@mit.edu> wrote:

You=E2=80=99ve got =E2=80=9CThe token remains opaque to the client=E2=80= =9D in there twice now. I had cut out the middle part the first sentence in= the second paragraph below, but that was hard to highlight. If you take my= text as-is that=E2=80=99s what I meant for the edited form.

=
Thanks
=C2=A0=E2=80=94 Justin

On Dec 1, 2015, at 2:18 PM, Phil Hunt <phil.hunt@oracle.com> w= rote:

Including Justin=E2=80=99s revision:
 =
 A large range of threats can be mitigated by protecting the content
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).

   To simplify discussion in the following examples, we assume that the
   token itself is integrity protected by the authorization server and
   the token remains opaque to the client.  The token itself cannot be
   modified by the client, either due to cryptographic protection (such
   as signature or encryption) or the use of a reference value with
   sufficient entropy and associated secure lookup.  The token remains
   opaque to the client.  These are characteristics shared with bearer
   tokens and more information on best practices can be found in
   [RFC6819] and in the security considerations section of [RFC6750].


On Dec 1, 2015, at 10:35 AM, Phil H= unt <phil.hunt= @oracle.com> wrote:

Thanks Justin. Your tweaks look good to me.

<= /div>

On Dec 1, 2015, at 10:28 AM, Kathle= en Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

<= div dir=3D"ltr">The changes work for me, thanks.

On Tue, Dec 1, 2015 at 1:27 PM, Justin= Richer <jricher@mit.edu> wrote:
That=E2=80=99s much better. I woul= d also suggest that a few edits to hammer home that this is an example
= 
 A large range of threats can be mitigated by protecting the content
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).  To
   simplify discussion in the foll=
owing example we assume=20
   that the token itself [=E2=80=A6]
   cannot be modified by the client, either due to cryptographic
   protection (such as signature or encryption) or use of a reference
   value with sufficient entropy and associated secure lookup.  The token remains opaque to the client.
These
   are characteristics shared with bearer tokens and more information on
   best practices can be found in [RFC6819] and in the security
   considerations section of [RFC6750].

<= /span>
That=E2=80=99s really what=E2=80=99s going on by my read. = Thoughts?

=C2=A0=E2= =80=94 Justin

On Dec 1, 2015, at 1:08 PM, Phil Hunt <phil.hunt@oracle.com> wrote:=

I=E2=80=99ve reviewed the comments from= John, Justin and Kathleen. As suggested, I plan to remove the erroneous fi= rst paragraph in section 5 (draft 06).

Combining the com= ments from this thread about sec 6, here is the proposed new first paragrap= h:

 A large range of threats can be mitigated by protecting the cont=
ent
   of the token, for example using a digital signature or a keyed
   message digest.  Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).  To
   simplify the subsequent description we assume in the PoP architecture
   that the token itself is integrity protected by the authorization
   server and the token remains opaque to the client.  The token itself
   cannot be modified by the client, either due to cryptographic
   protection (such as signature or encryption) or use of a reference
   value with sufficient entropy and associated secure lookup.  These
   are characteristics shared with bearer tokens and more information on
   best practices can be found in [RFC6819] and in the security
   considerations section of [RFC6750].
If this looks good to the= group, I=E2=80=99ll post draft 7 this afternoon (pacific).

<= /div>
Thanks,


On Nov 25, 2015, at 2:19 PM, Kathle= en Moriarty <Kathleen.Moriarty.ietf@gmail.com> wrote:

<= div dir=3D"ltr">

On Wed, Nov 25, 2015 at 3:58 PM, John Bradley <ve7jtb@ve7jtb.com>= ; wrote:
I am fine with that, however saying integrity protected, may be = better than signed.=C2=A0 May people will argue that HMAC or encryption wit= h sender verification is not signature.

Good point, I also prefer integrity protected.=C2=A0 Are we all good wit= h this now?=C2=A0 I'd like to look at a diff to make sure after followi= ng the thread.

Thanks!
Kathleen

=C2=A0
However they are perfectly valid.
=


On Nov 25, 2015= , at 5:53 PM, Justin Richer <jricher@mit.edu> wrote:

The requirement is not that signed JWTs be used, it=E2=80= =99s that unsigned JWTs not be used on their own. Reference tokens and encr= ypted JWTs are also valid, as are other signed formats like SAML assertions= or even a COSE Token (if it=E2=80=99s encoded to HTTP friendliness).=C2=A0=

My recommendation:

Remove the = erroneous requirement text from section 5 and restore to previous version.<= /div>

Amend the text in section 6 from:

   To
   simplify the subsequent description we assume in the PoP architecture

   that the token itself is digitally signed by the authorizatio=
n server
   and therefore cannot be modified.


To:

   In all such cases, the token r=
emains opaque to the client. To
   simplify the subsequent example and description we assume in the PoP arc=
hitecture
   that the token itself cannot be modified by the clie=
nt, either due to
   cryptographic protection (such as signature =
or encryption) or use of=C2=A0
   a reference value with sufficie=
nt entropy and associated secure lookup.
   These are characteris=
tics shared with bearer tokens and more information
   on best pr=
actices can be found in [[RFC6819]] and in the security=C2=A0
   =
considerations section of [[RFC6750]].


=
=C2=A0=E2=80=94 Justin

On Nov 25, 2015, at 3:39 PM, Kathleen Moriarty <kathleen.moriarty.ie= tf@gmail.com> wrote:

Hi,

Sent from my iPhone

On Nov = 25, 2015, at 3:20 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Tokens are signed or the information is otherwise inte= grity protected between the AS and the RS. =C2=A0

I susp= ect Kathleen is concerned about the key getting modified in transit. =C2=A0= =C2=A0
That needs to be protected against, but there is more than= one way to do that.

Phil is correct= .=C2=A0 I was looking for consistency between the sections since they relat= ed to each other.=C2=A0 If there is a security risk or consideration, that = needs to be explicitly called out as a concern such as a key being modified= in transit.=C2=A0 If there are options to protect against that, those woul= d ideally be required or would have warnings.
=

So sending the public key in a unsigned JWT access= token would be immensely stupid, =C2=A0not just for PoP but for scopes and= everything else.

Good, easy to requ= ire then.

Thanks,
Kathleen=C2=A0

In OAuth 2 all tokens need to be i= ntegrity protected between the AS and RS. =C2=A0
That can be via = signature, =C2=A0by having a reference with sufficient entropy and secure i= ntrospection or database lookup.

I think that is a= OAuth 2 security consideration. =C2=A0 We are adding a additional confirma= tion claim to the existing information that needs to be protected the same = as the rest.

John B.


=
On Nov 25, 2015, at 4:38 PM, Phil Hunt = <phil.hunt@ora= cle.com> wrote:

<editors hat= >
If there is agreement that tokens are opaque then the requir= ement that tokens be signed must be removed from the threat mitigation requ= irements.=C2=A0

And the paragraph in sec 5 that br= ian was concerned about be restored.=C2=A0

Phil

On Nov 25, 2015, at 11:24, Justin Richer <jricher@mit.edu> wrote:

It is still end to end authentication wi= th opaque tokens =E2=80=94 since all OAuth tokens, including PoP tokens, ha= ve always been intended to be opaque to the client. That hasn=E2=80=99t cha= nged and that isn=E2=80=99t the intent of this document. If that=E2=80=99s = how people are reading it then we need to pull it back and rewrite it so th= at=E2=80=99s not the case.

The client gets a token that = has two parts: the token and the key. The token is analogous to the access_= token we have today and would come out of the server in the same field. The= key is handed to the client alongside the token or registered by the clien= t during the token request. Either way there=E2=80=99s an association betwe= en the two but it=E2=80=99s not the same association as a public/private ke= ypair.=C2=A0

It=E2=80=99s possible to sign the tok= en itself, but the client doesn=E2=80=99t care. It sends the token and sign= s the HTTP request to the RS whether the token is signed, unsigned, hex blo= b, encrypted, or anything else. The same series of options are available as= with bearer tokens. PoP tokens have never, ever been intended to be anythi= ng but opaque to the client.

The token can=E2=80= =99t be opaque to the RS, which has to figure out what key to use to check = the message signature. But we=E2=80=99ve got options there, like the embedd= ed key in a JWT from Mike=E2=80=99s draft, or doing introspection to get th= e key (from an extension that hasn=E2=80=99t been written yet), or simply l= ooking it up in the same database because the RS and the AS are in the same= box. Does this structure/service/database choice sound familiar? It should= , it=E2=80=99s the same as bearer tokens. This is also how the RS gets info= rmation like which scopes are associated with the token, if it=E2=80=99s ex= pired, and all that.=C2=A0




So here=E2=80=99s how I see it going on the wire:



3D"http://www.=



(I just wrote this up so there are probably holes. Here=E2= =80=99s the source if anyone wants to tweak it:=C2=A0http://www.websequencediagrams.com/?lz= =3DcGFydGljaXBhbnQgQ2xpZW50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRo= b3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28= gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQ= IHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkI= GtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5= cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQU= AcBIKZW5kCgpDLT5SUzogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZA= CBbQYKUlMARAZjaGVjawCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY= 2sAgncFAIIYBWludHJvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAv= BWtleSAocHVibGljIG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwA= tBiBEQikAHQthAIQoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAI= JbBgCCXQVDOiByZXR1cm4AhicJ&s=3Dmodern-blue )

T= he client is oblivious to the token just like always. This is intentional. = The RS has the same options to figure out how to process the token.

=C2=A0=E2=80=94 Justin

On Nov 25, 2015, at 2:03 PM, Phil Hunt <phil.hunt@oracle.com> wrot= e:

Folks,=C2=A0

<edi= tor hat>
I did not want to go here either. :-)

<= /div>
I don=E2=80=99t read sec 6 as examples.=C2=A0 I believe this may = stem from the pop-architecture documents having a dual role as both =E2=80= =9Carchitecture=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D.=C2=A0 Maybe we sho= uld clarify the purpose of the document?

I believe= section 6 is talking about threat mitigation assumptions based on the exam= ples that need to be implemented.=C2=A0 I am assuming these are requirement= s that the other specifications SHOULD implement.

= <personal hat>
I do not believe we have discussed Opaque Po= P tokens and any inherent risks because the client is not or is unable to v= alidate the authenticity of the token.=C2=A0 Does this introduce the possib= ility of a MITM attack where a client can be convinced to sign requests for= an attacker?

If we want to include opaque PoP, I = think we need to take a pause and consider / discuss any threats here.

I find the desire for opaque PoP tokens to be a bit co= ntradictory. If we=E2=80=99re saying we don=E2=80=99t want to trust TLS alo= ne (e.g. because of load-balancer termination), why would we then say, but = we are perfectly willing to accept it worked for the OAuth AS exchanges?=C2= =A0 Maybe I was very wrong here, but my assumption all along is that for Po= P we=E2=80=99re talking about end-to-end authentication of all parties exce= pt in the case of 3.3 where we simply want to protect an access token over = a non-TLS HTTP connection.


On Nov 25, 2015, at 10:48 AM, Brian= Campbell <bcampbell@pingidentity.com> wrote:

While I can't say I disagree with the deeper existential que= stions about the draft that Justin raises, I was trying not to go there and= rather just point out concerns with the newly added text.

Th= e text Phil cites from Sec 6 doesn't say the client must be able to par= se and verify the token. It's an assumption to simplify the examples th= at follow and still the token is opaque to the client. I reread the whole d= raft (reluctantly) and there's nothing that says the token has to be no= n-opaque to the client. And it does talk about reference style tokens and e= ncrypted tokens, both of which rely on the opaqueness to the client.

On Wed,= Nov 25, 2015 at 11:27 AM, Justin Richer <jricher@mit.edu> wro= te:
R= ight, I read that as text for describing the examples and not for describin= g requirements.

The token itself doesn=E2=80=99t have to= be signed at all.

= =C2=A0=E2=80=94 Justin

On Nov 25, 2015, at 1:05 PM, Phil Hunt <phil.hunt@oracle.com>= ; wrote:

Ok. Well this was requested by Kathleen= because of this paragraph in Sec 6.=E2=80=A6

   To simplify the subsequent descripti=
on we assume in the PoP architecture
   that the token itself is digitally signed =
by the authorization server

   and=
 therefore cannot be modified.

Please=C2=A0

On Nov 25, 2015, at 9:33 AM, Justin= Richer <jricher@mi= t.edu> wrote:

The = token doesn=E2=80=99t have to be signed and the client doesn=E2=80=99t have= to verify the signature on the token. That=E2=80=99s not PoP. The request = has to be signed in a way that includes the token. The token itself can sti= ll be opaque. The *key* material can=E2=80=99t be opaque to the client, but= the *token* material still is.

I agree with Brian that = this statement is misleading.

The examples use a sig= ned token but that is absolutely not a requirement. Maybe the examples shou= ldn=E2=80=99t all use one style.

What=E2=80=99s mo= st difficult about this particular spec is that it=E2=80=99s very hand-wavy= , saying =E2=80=9Cthis is kinda a thing that kinda works like this=E2=80=9D= without saying how to actually do it. I=E2=80=99m honestly not sure it=E2= =80=99s worth publishing as an RFC in its own right but I=E2=80=99m not goi= ng to stand in its way.

=C2=A0=E2=80=94 Justin

On Nov 25, 2015, at 12:14 PM= , Brian Campbell <bcampbell@pingidentity.com> wrote:

Where does it say that?



On Wed, Nov 25, 2015 at 8:44 AM, Phil Hu= nt <phil.hunt@oracle.com> wrote:
Except that later on we require the token = be signed and the client verify that signed token. IOW mutual pop.=C2=A0

Phil
<= br>On Nov 25, 2015, at 07:30, Brian Campbell <bcampbell@pingidentity.com> wr= ote:

Looking a= t the diff I noticed the following new text, which seems to conflate bearer= /PoP and opaqueness to the client. A client demonstrating proof-of-possessi= on of some key is orthogonal to the client being able to parse and understa= nd the access token itself.
=C2=A0
"In contrast to bearer token= s [RFC6750] which call for tokens that are opaque to OAuth 2.0 clients, thi= s specification defines the requirements for proof-of-possession ("PoP= ") tokens that may be parsed and verified by OAuth 2.0 clients and rel= ying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt &l= t;phil.hunt@oracl= e.com> wrote:
This draft ad= dresses review comments from Kathleen and Erik raised since the last draft.=

It may not include some of the discussion from yesterday/today.=C2=A0 I wil= l add that as the group decides.

Cheers,

Phil

@independentid
www.independentid.com
phil.hunt@oracle.= com

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Phil Hunt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Justin Richer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 William Mills
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Prateek Mishra
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Hannes Tschofenig
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-oauth-pop-architecture-06.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 23
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2015-11-24
>
> Abstract:
>=C2=A0 =C2=A0The OAuth 2.0 bearer token specification, as defined in RF= C 6750,
>=C2=A0 =C2=A0allows any party in possession of a bearer token (a "= bearer") to get
>=C2=A0 =C2=A0access to the associated resources (without demonstrating = possession
>=C2=A0 =C2=A0of a cryptographic key).=C2=A0 To prevent misuse, bearer t= okens must be
>=C2=A0 =C2=A0protected from disclosure in transit and at rest.
>
>=C2=A0 =C2=A0Some scenarios demand additional security protection where= by a client
>=C2=A0 =C2=A0needs to demonstrate possession of cryptographic keying ma= terial when
>=C2=A0 =C2=A0accessing a protected resource.=C2=A0 This document motiva= tes the
>=C2=A0 =C2=A0development of the OAuth 2.0 proof-of-possession security = mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org= /doc/draft-ietf-oauth-pop-architecture/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/dra= ft-ietf-oauth-pop-architecture-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rf= cdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.<= br> >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@<= /td> <= span style=3D"text-decoration:none;font-family:arial,helvetica,sans-serif;f= ont-weight:normal;font-size:14px;padding:0px 0px 0px 3px">bcampbell@pingidentity.com
3D"phone" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">+1 720.317.2061
3D"twitter" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">@pingidentity
Connect with us!
3D"pingidentity.com"
3D"pingidentity.com" 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@<= /td> <= span style=3D"text-decoration:none;font-family:arial,helvetica,sans-serif;f= ont-weight:normal;font-size:14px;padding:0px 0px 0px 3px">bcampbell@pingidentity.com
3D"phone" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">+1 720.317.2061
3D"twitter" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">@pingidentity
Connect with us!
3D"pingidentity.com"
3D"pingidentity.com" 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth





--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@<= /td> <= span style=3D"text-decoration:none;font-family:arial,helvetica,sans-serif;f= ont-weight:normal;font-size:14px;padding:0px 0px 0px 3px">bcampbell@pingidentity.com
3D"phone" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">+1 720.317.2061
3D"twitter" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">@pingidentity
Connect with us!
3D"pingidentity.com"
3D"pingidentity.com" 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss


_______________________________________________OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailm= an/listinfo/oauth
____________= ___________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf= .org/mailman/listinfo/oauth




--

Be= st regards,
Kathleen
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth maili= ng list
OAuth@ietf.o= rg
https://www.ietf.org/mailman/listinfo/oauth




--

Best regards,
Kathleen

__________________________________= _____________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/= oauth

_____________________= __________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mail= man/listinfo/oauth

________= _______________________________________
OAuth mailing list
OAuth@ietf.org
https://www.= ietf.org/mailman/listinfo/oauth

<= /div>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--

Best regards,
Ka= thleen
--001a1145b64ec1647a0525de40e8-- From nobody Tue Dec 1 15:15:06 2015 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6220A1B29CD; Tue, 1 Dec 2015 15:15:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151201231503.24676.83201.idtracker@ietfa.amsl.com> Date: Tue, 01 Dec 2015 15:15:03 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 23:15:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture Authors : Phil Hunt Justin Richer William Mills Prateek Mishra Hannes Tschofenig Filename : draft-ietf-oauth-pop-architecture-07.txt Pages : 23 Date : 2015-12-01 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 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-architecture-07 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 1 15:17:34 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E750C1B29DB for ; Tue, 1 Dec 2015 15:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_yO_NwTqFRJ for ; Tue, 1 Dec 2015 15:17:31 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AC3A1B29D5 for ; Tue, 1 Dec 2015 15:17:31 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tB1NHUrP008562 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 1 Dec 2015 23:17:31 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tB1NHUCa021124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 1 Dec 2015 23:17:30 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tB1NHUXS006136 for ; Tue, 1 Dec 2015 23:17:30 GMT Received: from [10.0.1.22] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Dec 2015 15:17:30 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Phil Hunt In-Reply-To: <20151201231503.24676.83201.idtracker@ietfa.amsl.com> Date: Tue, 1 Dec 2015 15:17:28 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151201231503.24676.83201.idtracker@ietfa.amsl.com> To: "" X-Mailer: Apple Mail (2.3096.5) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 23:17:33 -0000 This submission includes the new section 6 introductory paragraph agreed = upon earlier this afternoon (pacific time). It also removes the first = paragraph in sec 5 that was introduced in error in draft 06. This should cover all the feedback received so far. Cheers, Phil @independentid www.independentid.com phil.hunt@oracle.com > On Dec 1, 2015, at 3:15 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Authorization Protocol Working = Group of the IETF. >=20 > Title : OAuth 2.0 Proof-of-Possession (PoP) Security = Architecture > Authors : Phil Hunt > Justin Richer > William Mills > Prateek Mishra > Hannes Tschofenig > Filename : draft-ietf-oauth-pop-architecture-07.txt > Pages : 23 > Date : 2015-12-01 >=20 > 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 be > protected from disclosure in transit and at rest. >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-07= >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Dec 1 16:04:07 2015 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A50AA1B2B37; Tue, 1 Dec 2015 16:04:04 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20151202000404.15752.96097.idtracker@ietfa.amsl.com> Date: Tue, 01 Dec 2015 16:04:04 -0800 Archived-At: Cc: draft-ietf-oauth-pop-architecture@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Last Call: (OAuth 2.0 Proof-of-Possession (PoP) Security Architecture) to Informational RFC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 00:04:04 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'OAuth 2.0 Proof-of-Possession (PoP) Security Architecture' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-12-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 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. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Dec 2 07:37:21 2015 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 036331A9113; Wed, 2 Dec 2015 07:37:17 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20151202153716.1608.92354.idtracker@ietfa.amsl.com> Date: Wed, 02 Dec 2015 07:37:16 -0800 Archived-At: Cc: oauth-chairs@ietf.org, oauth@ietf.org, draft-ietf-oauth-proof-of-possession@ietf.org Subject: [OAUTH-WG] Last Call: (Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 15:37:17 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-12-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines how to express a declaration in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular key and that the recipient can cryptographically confirm proof-of- possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Dec 4 13:05:57 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90FC1A8B84; Fri, 4 Dec 2015 13:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bFWnDbI7_ZE; Fri, 4 Dec 2015 13:05:49 -0800 (PST) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 904BB1A8AEA; Fri, 4 Dec 2015 13:05:48 -0800 (PST) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 4 Dec 2015 22:05:45 +0100 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Fri, 4 Dec 2015 22:05:45 +0100 From: =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= To: Kathleen Moriarty Thread-Topic: [COSE] Consensus Call: Adoption of the COSE Token Thread-Index: AQHRGTKb6mzibdroQ0aWbiONihL/Fp6mw9kAgAHRn4CAAEgoAIASjksA Date: Fri, 4 Dec 2015 21:05:45 +0000 Message-ID: References: <7505C89A-FCA1-4AD6-93F6-BDE3517AF1B4@mit.edu> <80EA3B4B-6FF2-42F4-8379-0C5D9E4ADE7A@gmail.com> In-Reply-To: <80EA3B4B-6FF2-42F4-8379-0C5D9E4ADE7A@gmail.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2104) x-originating-ip: [37.247.26.197] Content-Type: multipart/alternative; boundary="_000_C1C044D142DA443DB97243CFF444733Bnexusgroupcom_" MIME-Version: 1.0 Archived-At: Cc: "ace@ietf.org" , "" , "cose@ietf.org" Subject: Re: [OAUTH-WG] [COSE] Consensus Call: Adoption of the COSE Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 21:05:52 -0000 --_000_C1C044D142DA443DB97243CFF444733Bnexusgroupcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCldlIGp1c3Qgc3VibWl0dGVkIGFuIHVwZGF0ZWQgdmVyc2lvbiBvZiB0aGUgQ0JPUiBX ZWIgVG9rZW4gKENXVCkgdG8gdGhlIEFDRSBXRyByZXBvc2l0b3J5LiBUaGUgbmV3IHZlcnNpb24g cmVmZXJlbmNlcyB0aGUgSldUIGNsYWltcy4gTmFtZSBpcyBhbHNvIGtlcHQgdG8gQ0JPUiBXZWIg VG9rZW4gdG8gbWFrZSBpdCBjbGVhciBpdOKAmXMgZGVyaXZlZCBmcm9tIEpXVCBhbmQgdXNlcyBi b3RoIGNsYWltIG5hbWVzIGFuZCBmb3JtYXRzLg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtd2FobHN0cm9lbS1hY2UtY2Jvci13ZWItdG9rZW4tMDANCg0KLyBFcmlrLCBNaWtl IGFuZCBIYW5uZXMNCg0KDQpPbiAyMyBOb3YgMjAxNSwgYXQgMDI6NDMsIEthdGhsZWVuIE1vcmlh cnR5IDxrYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86a2F0aGxlZW4ubW9y aWFydHkuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCg0KSGVsbG8sDQoNCkxvb2tpbmcgYWNyb3Nz IHRoZSB0aHJlZSBXR3MsIHRoZXJlIGFyZSBnb29kIGFyZ3VtZW50cyBmb3IgZG9pbmcgdGhlIHdv cmsgaW4gZWFjaCwgYnV0IEFDRSB3b3VsZCBiZSB0aGUgYmVzdCBXRyBmb3IgYSBmZXcgcmVhc29u cy4NCg0KQ09TRSBpcyBzdXBwb3NlZCB0byBiZSBzaG9ydC1saXZlZCwgbGV0J3Mga2VlcCBpdCB0 aGF0IHdheS4NCg0KT0FVVEggaGFzIGEgZnVsbCBwbGF0ZSwgYWx0aG91Z2ggdGhleSB0ZW5kIHRv IGJlIHZlcnkgcHJvZHVjdGl2ZS4NCg0KQUNFIGhhcyBqdXN0IGJlY29tZSBtb3JlIGZvY3VzZWQg YW5kIEkgdGhpbmsgdGhpcyBjb3VsZCBmaXQgd2VsbCBvbmNlIHRoZSBPQVVUSCBzb2x1dGlvbiB3 b3JrIGlzIHVuZGVyd2F5Lg0KDQpUaGVyZSdzIGVub3VnaCBvdmVybGFwIGZvciB0aGlzIHRvIGhh cHBlbiBpbiBhbnkgb2YgdGhlIFdHcy4NCg0KVGhhbmtzIGZvciB0aGUgZGlzY3Vzc2lvbiwgSSB3 YXMgd2FpdGluZyB0byBjaGltZSBpbiB1bnRpbCBpdCB3YXMgaGFzaGVkIG91dCBhIGJpdCB0byBz ZWUgaWYgdGhlcmUgd2FzIGFueSBvdmVyd2hlbG1pbmcgY29uc2Vuc3VzIHdpdGhvdXQgaW5mbHVl bmNpbmcgdGhlIG91dGNvbWUuICBOb3cgdGhhdCBpdCBoYXMgcXVpZXRlZCBkb3duLCBBQ0UgaXMg cHJvYmFibHkgdGhlIGJlc3QgcGxhbi4NCg0KVGhhbmtzLA0KS2F0aGxlZW4NCg0KU2VudCBmcm9t IG15IGlQaG9uZQ0KDQpPbiBOb3YgMjIsIDIwMTUsIGF0IDQ6MjUgUE0sIEVyaWsgV2FobHN0csO2 bSBuZVh1cyA8ZXJpay53YWhsc3Ryb21AbmV4dXNncm91cC5jb208bWFpbHRvOmVyaWsud2FobHN0 cm9tQG5leHVzZ3JvdXAuY29tPj4gd3JvdGU6DQoNCkhpLA0KDQpZZXMsIHdlIGhhdmUgYSBkcmFm dCBwb3N0ZWQgaW4gdGhlIE9BdXRoIFdHIGZvciBhIENCT1IgV2ViIFRva2VuIChDV1QpLiBodHRw czovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXdhaGxzdHJvZW0tb2F1dGgtY2Jvci13ZWItdG9r ZW4tMDAudHh0DQoNCldlIHdhbnQgdG8ga2VlcCBpdCB0aGVyZSBhbmQgcmVmZXJlbmNlIHRoZSBK V1QgY2xhaW1zIChhbHNvIGRlZmluZWQgaW4gT0F1dGggV0cpIGFuZCBsYXRlciBhZGQgYXR0cmli dXRlcyBuZWVkZWQgZm9yIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIGZvciBJb1Qg dG8gSldUL0NXVCBpbiBBQ0UgV0cuDQoNClRoYW5rcw0KRXJpaw0KDQoNCg0KT24gMjEgTm92IDIw MTUsIGF0IDE4OjM5LCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQE1JVC5FRFU8bWFpbHRvOmpyaWNo ZXJATUlULkVEVT4+IHdyb3RlOg0KDQpSZWFkaW5nIHRocm91Z2ggdGhlIHRocmVhZHMgYW4gb3Bp bmlvbnMsIHRoZXJlIGlzIG5vIGNsZWFyIGNvbnNlbnN1cyBhcyB0byB3aGVyZSB0aGUgd29yayBz aG91bGQgYmUgZG9uZS4gVGhlcmUgaXMgcm91Z2hseSBlcXVhbCBzdXBwb3J0IGZvciBkb2luZyB0 aGlzIGluIGFueSBvZiB0aGUgdGhyZWUgb2ZmZXJlZCB3b3JraW5nIGdyb3Vwcy4NCg0KVGhlcmUg aXMgY2xlYXIgY29uc2Vuc3VzIHRoYXQgaXQgc2hvdWxkIGJlIGRvbmUgYW5kIHRoYXQsIGFzIG11 Y2ggYXMgcG9zc2libGUsIGl0IHNob3VsZCBiZSBhIGRpcmVjdCBtYXAgb2YgdGhlIGV4aXN0aW5n IEpXVCBwYXlsb2FkIG9iamVjdCBhbmQgY29tbW9uIGNsYWltcy4NCg0KSW4gdGhpcyBsaWdodCwg c29tZW9uZSBuZWVkcyB0byBqdXN0IHN0YXJ0IHRoZSB3b3JrIGFzIGFuIGluZGl2aWR1YWwgZHJh ZnQgYW5kIHB1c2ggZm9yd2FyZCwgYW5kIHdoaWNoZXZlciB3b3JraW5nIGdyb3VwIG1vc3Qgd2Fu dHMgdG8gY2FuIHBpY2sgaXQgdXAgYW5kIHB1Ymxpc2ggaXQuIEkgaGF2ZSBubyBxdWFsbXMgb24g YWNjZXB0aW5nIHRoaXMgd29yayB3aXRoaW4gdGhlIENPU0Ugd29ya2luZyBncm91cCBhbmQgSSBi ZWxpZXZlIHRoZXJlIGlzIGVub3VnaCBzdXBwb3J0IHRvIHdhcnJhbnQgdGhhdCBwbGFjZW1lbnQg aWYgYW4gYXV0aG9yIHN1Ym1pdHMgYSBkcmFmdCBoZXJlIChhbmQgdGhpcyByZW1haW5zIG15IHBy ZWZlcmVuY2UgYXMgYW4gaW5kaXZpZHVhbCksIGJ1dCBJIHdpbGwgbm90IG9iamVjdCB0byBhbm90 aGVyIGdyb3VwIHBpY2tpbmcgaXQgdXAuDQoNCkkgYmVsaWV2ZSwgd2l0aCBhbGwgb2YgdGhlIG92 ZXJsYXAgYmV0d2VlbiBncm91cHMsIHRoYXQgd2Ugd2lsbCBoYXZlIG5vIHRyb3VibGUgZ2V0dGlu ZyB0aGUg4oCccmlnaHQgcGVvcGxl4oCdIHRvIGxvb2sgYXQgaXQuIEFkZGl0aW9uYWxseSwgaXQg aXMgY2xlYXIgdGhhdCBpdCB3aWxsIGJlIHZlcnkgYmVuZWZpY2lhbCB0byBoYXZlIGZvcm1hbCBy ZXZpZXdzIGZyb20gYWxsIHRocmVlIGdyb3VwcyBvbmNlIHRoZSBkcmFmdCBoYXMgcmVhY2hlZCBh IG1hdHVyZSBzdGF0dXMuDQoNClRoYW5rZnVsbHksIEVyaWsgaGFzIGFscmVhZHkgZG9uZSB0aGlz IHdpdGggaGlzIOKAnENPU0UgV2ViIFRva2Vu4oCdIGRyYWZ0LiBIZeKAmXMgaW5pdGlhbGx5IHRh cmdldGVkIHRoaXMgYXQgdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAsIGFuZCB0aGUgd29yayBzdGFy dGVkIGluIEFDRSwgc28gSSBjYWxsIHRvIHRoZSBhdXRob3IgdG8gcGljayBhIGxvY2F0aW9uIGFu ZCBydW4gd2l0aCBpdC4NCg0K4oCUIEp1c3RpbiwgeW91ciBDT1NFIGNoYWlyDQoNCk9uIE5vdiA3 LCAyMDE1LCBhdCAzOjAxIEFNLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQE1JVC5FRFU8bWFpbHRv OmpyaWNoZXJATUlULkVEVT4+IHdyb3RlOg0KDQpBdCB0aGUgWW9rb2hhbWEgbWVldGluZywgdGhl IGNoYWlycyBhZ3JlZWQgdG8gZG8gYSBjb25zZW5zdXMgY2FsbCByZWdhcmRpbmcgdGhlIGFkb3B0 aW9uIGFuZCBwbGFjZW1lbnQgb2YgbmV3IHdvcmsgdG8gZGVmaW5lIGEgQ09TRSBUb2tlbiwgYW5h bG9nb3VzIHRvIHRoZSBKV1QgZnJvbSBKT1NFLiBJbiB0aGUgcm9vbSwgdGhlcmUgd2FzIGEgZ2Vu ZXJhbCBzZW50aW1lbnQgb2Ygc3VwcG9ydCBmb3IgdGhlIHdvcmsgYmVpbmcgZG9uZSwgd2l0aCB0 aGUgd2lkZSBhZG9wdGlvbiBvZiBKV1QgYW5kIGl0cyBkcml2aW5nIG9mIEpPU0UgYmVpbmcgYSBj b21tb24gdGhlbWUgb2YgcHJlY2VkZW50LiBXaGF0IHdhc27igJl0IGNsZWFyIGlzIHdoZXJlIHRo ZSB3b3JrIHNob3VsZCBiZSBkb25lIGFuZCB0byB3aGF0IGVuZCBpdCBzaG91bGQgZHJpdmUuIFRo ZSBzaXggcG9zaXRpb25zIHdlIGFyZSBhc2tpbmcgdGhlIHdvcmtpbmcgZ3JvdXAgdG8gY29uc2lk ZXIgYW5kIHZvaWNlIHRoZWlyIHN1cHBvcnQgZm9yIGFyZToNCg0KQSkgRGVmaW5lIHRoZSBDT1NF IFRva2VuIHdpdGhpbiB0aGUgQ09TRSB3b3JraW5nIGdyb3VwIGFsb25nIHNpZGUgdGhlIENPU0Ug TWVzc2FnZXMgKGFuZCBwb3RlbnRpYWxseSBDT1NFIEF1eGlsaWFyeSBBbGdvcml0aG1zKSBkcmFm dC4NCkIpIERlZmluZSB0aGUgQ09TRSBUb2tlbiBpbnNpZGUgdGhlIE9BdXRoIHdvcmtpbmcgZ3Jv dXAuDQpDKSBEZWZpbmUgdGhlIENPU0UgVG9rZW4gaW5zaWRlIHRoZSBBQ0Ugd29ya2luZyBncm91 cC4NCkQpIERvbuKAmXQgZGVmaW5lIHRoZSBDT1NFIFRva2VuIGFueXdoZXJlLg0KRSkgWW91IG5l ZWQgbW9yZSBpbmZvcm1hdGlvbiB0byBkZWNpZGUuDQpGKSBZb3UgZG9u4oCZdCBnaXZlIGEgZmx5 aW5nIHJhdCBhYm91dCB0aGUgQ09TRSBUb2tlbi4qDQoNClRoZSBjb25zZW5zdXMgY2FsbCB3aWxs IHJlbWFpbiBvcGVuIGZvciB0d28gd2Vla3MgZnJvbSB0b2RheSwgY2xvc2luZyBvbiBOb3ZlbWJl ciAyMSwgMjAxNTsgYXQgd2hpY2ggdGltZSwgaG9wZWZ1bGx5IHdlIHdpbGwgaGF2ZSBhIGNsZWFy IGFuc3dlciBhbmQgZGlyZWN0aW9uIHRvIHBvaW50IHRoaXMgd29yay4NCg0KVGhhbmsgeW91LA0K 4oCUIEp1c3RpbiAmIEtlcGVuZywgeW91ciBDT1NFIGNoYWlycw0KDQoqIEkgcHJvbWlzZWQgdGhv c2UgaW4gdGhlIHJvb20gYXQgWW9rb2hhbWEgdG8gb2ZmZXIgYSBmbHlpbmcgcmF0IG9wdGlvbiwg Zm9yIHdoaWNoIEkgYW0gZGVlcGx5IHNvcnJ5Lg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkNPU0UgbWFpbGluZyBsaXN0DQpDT1NFQGlldGYub3JnPG1h aWx0bzpDT1NFQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jb3NlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpDT1NFIG1haWxpbmcgbGlzdA0KQ09TRUBpZXRmLm9yZzxtYWlsdG86Q09TRUBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29zZQ0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ09TRSBtYWlsaW5nIGxpc3QN CkNPU0VAaWV0Zi5vcmc8bWFpbHRvOkNPU0VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UNCg0K --_000_C1C044D142DA443DB97243CFF444733Bnexusgroupcom_ Content-Type: text/html; charset="utf-8" Content-ID: <48B9DE0308B3B44BBD95A5DD3A6B879B@nexusgroup.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IaSw8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPldl IGp1c3Qgc3VibWl0dGVkIGFuIHVwZGF0ZWQgdmVyc2lvbiBvZiB0aGUgQ0JPUiBXZWIgVG9rZW4g KENXVCkgdG8gdGhlIEFDRSBXRyByZXBvc2l0b3J5LiBUaGUgbmV3IHZlcnNpb24gcmVmZXJlbmNl cyB0aGUgSldUIGNsYWltcy4gTmFtZSBpcyBhbHNvIGtlcHQgdG8gQ0JPUiBXZWIgVG9rZW4gdG8g bWFrZSBpdCBjbGVhciBpdOKAmXMgZGVyaXZlZCBmcm9tIEpXVCBhbmQgdXNlcyBib3RoIGNsYWlt IG5hbWVzIGFuZCBmb3JtYXRzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXdhaGxzdHJvZW0tYWNlLWNib3Itd2ViLXRva2VuLTAwIiBjbGFzcz0iIj5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FobHN0cm9lbS1hY2UtY2Jvci13ZWItdG9rZW4t MDA8L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4vIEVyaWssIE1pa2UgYW5kIEhhbm5lczwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gMjMgTm92IDIwMTUsIGF0IDAyOjQz LCBLYXRobGVlbiBNb3JpYXJ0eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5 LmlldGZAZ21haWwuY29tIiBjbGFzcz0iIj5rYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNv bTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXds aW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPkhlbGxvLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+TG9va2luZyBhY3Jvc3MgdGhlIHRocmVlIFdHcywgdGhlcmUgYXJlIGdv b2QgYXJndW1lbnRzIGZvciBkb2luZyB0aGUgd29yayBpbiBlYWNoLCBidXQgQUNFIHdvdWxkIGJl IHRoZSBiZXN0IFdHIGZvciBhIGZldyByZWFzb25zLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q09TRSBpcyBzdXBwb3NlZCB0byBiZSBz aG9ydC1saXZlZCwgbGV0J3Mga2VlcCBpdCB0aGF0IHdheS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk9BVVRIIGhhcyBhIGZ1bGwgcGxh dGUsIGFsdGhvdWdoIHRoZXkgdGVuZCB0byBiZSB2ZXJ5IHByb2R1Y3RpdmUuPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BQ0UgaGFzIGp1 c3QgYmVjb21lIG1vcmUgZm9jdXNlZCBhbmQgSSB0aGluayB0aGlzIGNvdWxkIGZpdCB3ZWxsIG9u Y2UgdGhlIE9BVVRIIHNvbHV0aW9uIHdvcmsgaXMgdW5kZXJ3YXkuPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGVyZSdzIGVub3VnaCBv dmVybGFwIGZvciB0aGlzIHRvIGhhcHBlbiBpbiBhbnkgb2YgdGhlIFdHcy48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyBmb3Ig dGhlIGRpc2N1c3Npb24sIEkgd2FzIHdhaXRpbmcgdG8gY2hpbWUgaW4gdW50aWwgaXQgd2FzIGhh c2hlZCBvdXQgYSBiaXQgdG8gc2VlIGlmIHRoZXJlIHdhcyBhbnkgb3ZlcndoZWxtaW5nIGNvbnNl bnN1cyB3aXRob3V0IGluZmx1ZW5jaW5nIHRoZSBvdXRjb21lLiAmbmJzcDtOb3cgdGhhdCBpdCBo YXMgcXVpZXRlZCBkb3duLCBBQ0UgaXMgcHJvYmFibHkgdGhlIGJlc3QgcGxhbi48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyw8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+S2F0aGxlZW4mbmJzcDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpTZW50IGZyb20gbXkgaVBob25lPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCk9uIE5vdiAyMiwgMjAxNSwgYXQgNDoyNSBQTSwgRXJpayBXYWhsc3Ryw7ZtIG5lWHVz ICZsdDs8YSBocmVmPSJtYWlsdG86ZXJpay53YWhsc3Ryb21AbmV4dXNncm91cC5jb20iIGNsYXNz PSIiPmVyaWsud2FobHN0cm9tQG5leHVzZ3JvdXAuY29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+SGksDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5ZZXMsIHdlIGhhdmUgYSBkcmFmdCBwb3N0ZWQgaW4gdGhlIE9B dXRoIFdHIGZvciBhIENCT1IgV2ViIFRva2VuIChDV1QpLiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtd2FobHN0cm9lbS1vYXV0aC1jYm9yLXdlYi10b2tlbi0w MC50eHQiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtd2FobHN0cm9l bS1vYXV0aC1jYm9yLXdlYi10b2tlbi0wMC50eHQ8L2E+Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XZSB3YW50IHRvIGtlZXAg aXQgdGhlcmUgYW5kIHJlZmVyZW5jZSB0aGUgSldUIGNsYWltcyAoYWxzbyBkZWZpbmVkIGluIE9B dXRoIFdHKSBhbmQgbGF0ZXIgYWRkIGF0dHJpYnV0ZXMgbmVlZGVkIGZvciBhdXRoZW50aWNhdGlv biBhbmQgYXV0aG9yaXphdGlvbiBmb3IgSW9UIHRvIEpXVC9DV1QgaW4gQUNFIFdHLjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtz PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkVyaWs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDIxIE5vdiAyMDE1LCBhdCAxODozOSwg SnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJATUlULkVEVSIgY2xhc3M9 IiI+anJpY2hlckBNSVQuRURVPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxl LWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj5SZWFkaW5nIHRocm91Z2ggdGhl IHRocmVhZHMgYW4gb3BpbmlvbnMsIHRoZXJlIGlzIG5vIGNsZWFyIGNvbnNlbnN1cyBhcyB0byB3 aGVyZSB0aGUgd29yayBzaG91bGQgYmUgZG9uZS4gVGhlcmUgaXMgcm91Z2hseSBlcXVhbCBzdXBw b3J0IGZvciBkb2luZyB0aGlzIGluIGFueSBvZiB0aGUgdGhyZWUgb2ZmZXJlZCB3b3JraW5nIGdy b3Vwcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGVyZSBpcyBjbGVhciBjb25zZW5z dXMgdGhhdCBpdCBzaG91bGQgYmUgZG9uZSBhbmQgdGhhdCwgYXMgbXVjaCBhcyBwb3NzaWJsZSwg aXQgc2hvdWxkIGJlIGEgZGlyZWN0IG1hcCBvZiB0aGUgZXhpc3RpbmcgSldUIHBheWxvYWQgb2Jq ZWN0IGFuZCBjb21tb24gY2xhaW1zLg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSW4g dGhpcyBsaWdodCwgc29tZW9uZSBuZWVkcyB0byBqdXN0IHN0YXJ0IHRoZSB3b3JrIGFzIGFuIGlu ZGl2aWR1YWwgZHJhZnQgYW5kIHB1c2ggZm9yd2FyZCwgYW5kIHdoaWNoZXZlciB3b3JraW5nIGdy b3VwIG1vc3Qgd2FudHMgdG8gY2FuIHBpY2sgaXQgdXAgYW5kIHB1Ymxpc2ggaXQuIEkgaGF2ZSBu byBxdWFsbXMgb24gYWNjZXB0aW5nIHRoaXMgd29yayB3aXRoaW4gdGhlIENPU0Ugd29ya2luZyBn cm91cCBhbmQgSSBiZWxpZXZlIHRoZXJlIGlzDQogZW5vdWdoIHN1cHBvcnQgdG8gd2FycmFudCB0 aGF0IHBsYWNlbWVudCBpZiBhbiBhdXRob3Igc3VibWl0cyBhIGRyYWZ0IGhlcmUgKGFuZCB0aGlz IHJlbWFpbnMgbXkgcHJlZmVyZW5jZSBhcyBhbiBpbmRpdmlkdWFsKSwgYnV0IEkgd2lsbCBub3Qg b2JqZWN0IHRvIGFub3RoZXIgZ3JvdXAgcGlja2luZyBpdCB1cC48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpJIGJlbGlldmUsIHdpdGggYWxsIG9mIHRoZSBvdmVybGFwIGJldHdlZW4gZ3Jv dXBzLCB0aGF0IHdlIHdpbGwgaGF2ZSBubyB0cm91YmxlIGdldHRpbmcgdGhlIOKAnHJpZ2h0IHBl b3BsZeKAnSB0byBsb29rIGF0IGl0LiBBZGRpdGlvbmFsbHksIGl0IGlzIGNsZWFyIHRoYXQgaXQg d2lsbCBiZSB2ZXJ5IGJlbmVmaWNpYWwgdG8gaGF2ZSBmb3JtYWwgcmV2aWV3cyBmcm9tIGFsbCB0 aHJlZSBncm91cHMgb25jZSB0aGUgZHJhZnQgaGFzIHJlYWNoZWQgYSBtYXR1cmUNCiBzdGF0dXMu IDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoYW5rZnVsbHksIEVyaWsgaGFzIGFscmVh ZHkgZG9uZSB0aGlzIHdpdGggaGlzIOKAnENPU0UgV2ViIFRva2Vu4oCdIGRyYWZ0LiBIZeKAmXMg aW5pdGlhbGx5IHRhcmdldGVkIHRoaXMgYXQgdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAsIGFuZCB0 aGUgd29yayBzdGFydGVkIGluIEFDRSwgc28gSSBjYWxsIHRvIHRoZSBhdXRob3IgdG8gcGljayBh IGxvY2F0aW9uIGFuZCBydW4gd2l0aCBpdC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQri gJQgSnVzdGluLCB5b3VyIENPU0UgY2hhaXI8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5PbiBOb3YgNywgMjAxNSwgYXQgMzowMSBB TSwgSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJATUlULkVEVSIgY2xh c3M9IiI+anJpY2hlckBNSVQuRURVPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KQXQgdGhlIFlva29oYW1hIG1lZXRpbmcsIHRoZSBjaGFpcnMgYWdyZWVkIHRvIGRv IGEgY29uc2Vuc3VzIGNhbGwgcmVnYXJkaW5nIHRoZSBhZG9wdGlvbiBhbmQgcGxhY2VtZW50IG9m IG5ldyB3b3JrIHRvIGRlZmluZSBhIENPU0UgVG9rZW4sIGFuYWxvZ291cyB0byB0aGUgSldUIGZy b20gSk9TRS4gSW4gdGhlIHJvb20sIHRoZXJlIHdhcyBhIGdlbmVyYWwgc2VudGltZW50IG9mIHN1 cHBvcnQgZm9yIHRoZSB3b3JrIGJlaW5nIGRvbmUsIHdpdGggdGhlDQogd2lkZSBhZG9wdGlvbiBv ZiBKV1QgYW5kIGl0cyBkcml2aW5nIG9mIEpPU0UgYmVpbmcgYSBjb21tb24gdGhlbWUgb2YgcHJl Y2VkZW50LiBXaGF0IHdhc27igJl0IGNsZWFyIGlzIHdoZXJlIHRoZSB3b3JrIHNob3VsZCBiZSBk b25lIGFuZCB0byB3aGF0IGVuZCBpdCBzaG91bGQgZHJpdmUuIFRoZSBzaXggcG9zaXRpb25zIHdl IGFyZSBhc2tpbmcgdGhlIHdvcmtpbmcgZ3JvdXAgdG8gY29uc2lkZXIgYW5kIHZvaWNlIHRoZWly IHN1cHBvcnQgZm9yIGFyZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBKSBEZWZpbmUg dGhlIENPU0UgVG9rZW4gd2l0aGluIHRoZSBDT1NFIHdvcmtpbmcgZ3JvdXAgYWxvbmcgc2lkZSB0 aGUgQ09TRSBNZXNzYWdlcyAoYW5kIHBvdGVudGlhbGx5IENPU0UgQXV4aWxpYXJ5IEFsZ29yaXRo bXMpIGRyYWZ0LjxiciBjbGFzcz0iIj4NCkIpIERlZmluZSB0aGUgQ09TRSBUb2tlbiBpbnNpZGUg dGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAuPGJyIGNsYXNzPSIiPg0KQykgRGVmaW5lIHRoZSBDT1NF IFRva2VuIGluc2lkZSB0aGUgQUNFIHdvcmtpbmcgZ3JvdXAuPGJyIGNsYXNzPSIiPg0KRCkgRG9u 4oCZdCBkZWZpbmUgdGhlIENPU0UgVG9rZW4gYW55d2hlcmUuPGJyIGNsYXNzPSIiPg0KRSkgWW91 IG5lZWQgbW9yZSBpbmZvcm1hdGlvbiB0byBkZWNpZGUuPGJyIGNsYXNzPSIiPg0KRikgWW91IGRv buKAmXQgZ2l2ZSBhIGZseWluZyByYXQgYWJvdXQgdGhlIENPU0UgVG9rZW4uKjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NClRoZSBjb25zZW5zdXMgY2FsbCB3aWxsIHJlbWFpbiBvcGVuIGZv ciB0d28gd2Vla3MgZnJvbSB0b2RheSwgY2xvc2luZyBvbiBOb3ZlbWJlciAyMSwgMjAxNTsgYXQg d2hpY2ggdGltZSwgaG9wZWZ1bGx5IHdlIHdpbGwgaGF2ZSBhIGNsZWFyIGFuc3dlciBhbmQgZGly ZWN0aW9uIHRvIHBvaW50IHRoaXMgd29yay48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpU aGFuayB5b3UsPGJyIGNsYXNzPSIiPg0K4oCUIEp1c3RpbiAmYW1wOyBLZXBlbmcsIHlvdXIgQ09T RSBjaGFpcnM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQoqIEkgcHJvbWlzZWQgdGhvc2Ug aW4gdGhlIHJvb20gYXQgWW9rb2hhbWEgdG8gb2ZmZXIgYSBmbHlpbmcgcmF0IG9wdGlvbiwgZm9y IHdoaWNoIEkgYW0gZGVlcGx5IHNvcnJ5LjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KQ09TRSBtYWlsaW5n IGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86Q09TRUBpZXRmLm9yZyIgY2xhc3M9 IiI+Q09TRUBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY29zZTwvYT48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+ DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxiciBjbGFzcz0iIj4NCkNPU0UgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEg aHJlZj0ibWFpbHRvOkNPU0VAaWV0Zi5vcmciIGNsYXNzPSIiPkNPU0VAaWV0Zi5vcmc8L2E+PGJy IGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jb3NlIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nv c2U8L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyIGNsYXNzPSIi Pg0KPHNwYW4gY2xhc3M9IiI+Q09TRSBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIGNsYXNzPSIiPg0K PHNwYW4gY2xhc3M9IiI+PGEgaHJlZj0ibWFpbHRvOkNPU0VAaWV0Zi5vcmciIGNsYXNzPSIiPkNP U0VAaWV0Zi5vcmc8L2E+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29zZSIgY2xhc3M9IiI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlPC9hPjwvc3Bhbj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C1C044D142DA443DB97243CFF444733Bnexusgroupcom_-- From nobody Fri Dec 4 19:05:34 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC011B3658 for ; Fri, 4 Dec 2015 19:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scktXxk87w2U for ; Fri, 4 Dec 2015 19:05:24 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0146.outbound.protection.outlook.com [207.46.100.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CE5E1B365C for ; Fri, 4 Dec 2015 19:05:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hLOquqT5IBusng9RngxJZj/ISUUd+2oGtxobVgk3raM=; b=VDWEnbyZiN/Xynaz1ZDj1FO1Lu8LxOinkgXgw4iGRFbmcje3U6vmdrXnyakOXEdviwwnR01W+WkKf/GfRhdE+8O7HoqkYj8VqxMZtJOd1mp/SfFptTApWnvF4aquCHKYXD9ZkF2uAlFibPkmUuMOvKSuT5IEmX21P3gQsX0lxOs= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.331.20; Sat, 5 Dec 2015 03:05:23 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Sat, 5 Dec 2015 03:05:23 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Authentication Method Reference Values Registration Instructions Thread-Index: AdEvByk8C8rB/x+yTJ+7SIMNc/vAhw== Date: Sat, 5 Dec 2015 03:05:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:2::650] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:TJRbyUfHDVkug5Vn8/39HvpmQinWmQUjZ6sFYDbJ1Z7bIUpfT+mVN7eKqBVQZ5nejG6z9YWbLZMjgn/Z7wVhTmALsGHwbDo3+lrKvX97+b6yvJfnjWZBIWU8x6cZFnHWR1d7K2oRM+LmXlnWaZPvwg==; 24:Ih4mDBCuJ+o/3QYX+NCc3sqqWkaPHXYYwYG7XCI7B9aYYX+3K1NoDswV/S06y78T9hOX/RBTrGMFM5YvTMCD/aJT1cvha2ISQA9nLzMULHA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 07817FCC2D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(189002)(199003)(97736004)(86362001)(10290500002)(5004730100002)(81156007)(450100001)(10400500002)(77096005)(110136002)(86612001)(8990500004)(1096002)(15975445007)(5008740100001)(19300405004)(11100500001)(5001960100002)(19625215002)(6116002)(107886002)(2900100001)(586003)(790700001)(99286002)(102836003)(92566002)(74316001)(101416001)(105586002)(106356001)(5005710100001)(5002640100001)(54356999)(189998001)(19617315012)(1220700001)(16236675004)(40100003)(19580395003)(2351001)(122556002)(33656002)(76576001)(5003600100002)(50986999)(2501003)(10090500001)(87936001)(229853001)(3826002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4428F01D93DFD5AE2B2171BF50B0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2015 03:05:22.8635 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Subject: [OAUTH-WG] Authentication Method Reference Values Registration Instructions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2015 03:05:32 -0000 --_000_BY2PR03MB4428F01D93DFD5AE2B2171BF50B0BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authentication Method Reference Values draft -03 adds the criterion to the = IANA registration instructions that the value being registered be in actual= use. The specification is available at: * http://tools.ietf.org/html/draft-jones-oauth-amr-values-03 An HTML formatted version is also available at: * http://self-issued.info/docs/draft-jones-oauth-amr-values-03.html -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1501 and as= @selfissued. --_000_BY2PR03MB4428F01D93DFD5AE2B2171BF50B0BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Authentication Method Reference Va= lues draft -03 adds the criterion to the IANA registration instructions tha= t the value being registered be in actual use.

 

The specification is available at:

·         http://tools.ietf.org/html/draft-jones-oauth-amr= -values-03

 

An HTML formatted version is also available at:=

·         http://self-issued.info/docs/draft-jones-= oauth-amr-values-03.html

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

P.S.  This note was also posted at http://self-issued.info/?p=3D1501 and as @selfissued.

 

--_000_BY2PR03MB4428F01D93DFD5AE2B2171BF50B0BY2PR03MB442namprd_-- From nobody Fri Dec 4 19:49:59 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB211B2F5C for ; Fri, 4 Dec 2015 19:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awPmGdd5qmd9 for ; Fri, 4 Dec 2015 19:49:55 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0778.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::778]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 562211B2F46 for ; Fri, 4 Dec 2015 19:49:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/ASGm6Gt7TE20FMic9DUbDtIRZZvsZFQHH8opuMvVks=; b=fuw2Ft437y0kkGmKuMYGlBAZ+zbE0vTx0bWOthiQpv74Pd2aD5JZi33lsGBlc1decbr3Ux2Seo+RXlyAb95SBJvIHA1+W5aNufA+PR+jZAjop7ZJNz0G51IBI02uIgTR1KM6IhRcv+xSEyOw3ikTos8bcwBNlBJM2mGaSQGuxD4= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.331.20; Sat, 5 Dec 2015 03:49:36 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Sat, 5 Dec 2015 03:49:36 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: CBOR Web Token (CWT) spec for the ACE working group Thread-Index: AdEvDD/qhV0xKgF3TQ+OV37TSTGCSwAA461w Date: Sat, 5 Dec 2015 03:49:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:2::650] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:aFLfHkVPSaJskPf8x9Yt1DN9lsdFO1dwPWNpsgelXU3VIMC0CESUGakWm/SVJX80b387wbBu1Ldwg8VyPAfTiEjlnXqN7aK7rys5dFq2JvlNaBjCMnxNSRA5oe2tbmMhUZTEEa/KNX/oiEfp98/qVQ==; 24:iOctoiJeEBws1tR+HmEM2kw8HZSTjGze3+6+AMDlCk2EiuFeTFTCG9rldsWtiskTMtPhb3IhLv1elcJ23yQPvLA1K+5i69D/tIxFeEimwBc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 07817FCC2D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(199003)(377454003)(189002)(1220700001)(19617315012)(189998001)(5002640100001)(54356999)(19580405001)(19580395003)(40100003)(16236675004)(106356001)(5005710100001)(10090500001)(87936001)(2351001)(33656002)(122556002)(50986999)(2501003)(76576001)(5003600100002)(8990500004)(86612001)(110136002)(11100500001)(5001960100002)(19300405004)(1096002)(5008740100001)(15975445007)(10290500002)(97736004)(86362001)(5004730100002)(77096005)(10400500002)(81156007)(450100001)(102836003)(92566002)(99286002)(107886002)(105586002)(101416001)(74316001)(6116002)(19625215002)(586003)(790700001)(2900100001)(3826002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4427B155928E73D1A68D933F50B0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2015 03:49:36.8209 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Subject: [OAUTH-WG] FW: CBOR Web Token (CWT) spec for the ACE working group X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2015 03:49:58 -0000 --_000_BY2PR03MB4427B155928E73D1A68D933F50B0BY2PR03MB442namprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This specification replaces http://tools.ietf.org/html/draft-wahlstroem-oau= th-cbor-web-token-00. -- Mike From: Mike Jones Sent: Friday, December 4, 2015 7:47 PM To: ace@ietf.org Subject: CBOR Web Token (CWT) spec for the ACE working group After input from many interested people, IETF Security Area Director Kathle= en Moriarty decided that the right place for the CBOR Web Token (CWT) work is the ACE= working group. Today Erik Wa= hlstr=F6m posted a new draft of the CBOR Web Token (CWT) specification that= is intended for ACE. This version of the spec references the JSON Web Token (JWT) claim definitions, rather than repeating them, and in= tentionally only includes equivalents of the claims defined by the JWT spec= . Other CWT claims, including those needed by ACE applications, will be de= fined by other specs and registered in the CWT claims registry. The specification is available at: =B7 http://tools.ietf.org/html/draft-wahlstroem-ace-cbor-web-token-= 00 An HTML-formatted version is also available at: =B7 http://self-issued.info/docs/draft-wahlstroem-ace-cbor-web-toke= n-00.html -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1503 and as= @selfissued. --_000_BY2PR03MB4427B155928E73D1A68D933F50B0BY2PR03MB442namprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This specification rep= laces http://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          -- Mike=

 

From: Mike Jones
Sent: Friday, December 4, 2015 7:47 PM
To: ace@ietf.org
Subject: CBOR Web Token (CWT) spec for the ACE working group

 

After input from many interested people, IETF Securi= ty Area Director Kathleen Moriarty decided that the right place for the CBOR Web Token = (CWT) work is the ACE working group.  Today Erik Wahlstr=F6m posted a new draft of the CBOR Web Token (= CWT) specification that is intended for ACE.

 

This version of the spec references the JSON Web Token (JWT) claim definitions, rather than repeating them, and= intentionally only includes equivalents of the claims defined by the JWT s= pec.  Other CWT claims, including those needed by ACE applications, wi= ll be defined by other specs and registered in the CWT claims registry.

 

The specification is available at:

=B7         http://tools.ietf.org/html/= draft-wahlstroem-ace-cbor-web-token-00

 

An HTML-formatted version is also available at:=

=B7         http://self-issued.i= nfo/docs/draft-wahlstroem-ace-cbor-web-token-00.html<= /p>

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

P.S.  This note was also posted at http://self-issued.info/?p=3D1503 and as @selfissued.

--_000_BY2PR03MB4427B155928E73D1A68D933F50B0BY2PR03MB442namprd_-- From nobody Tue Dec 8 07:07:22 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4577B1B2ED6; Tue, 8 Dec 2015 07:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIXYAiGSBYzt; Tue, 8 Dec 2015 07:07:10 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0D31B2EC5; Tue, 8 Dec 2015 07:07:10 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 1B4581832BB; Tue, 8 Dec 2015 07:05:08 -0800 (PST) To: david.gladstone@nib.co.nz, torsten@lodderstedt.net, mark.mcgloin@ie.ibm.com, phil.hunt@yahoo.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20151208150508.1B4581832BB@rfc-editor.org> Date: Tue, 8 Dec 2015 07:05:08 -0800 (PST) Archived-At: Cc: rfc-editor@rfc-editor.org, Kathleen.Moriarty@emc.com, iesg@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] [Errata Held for Document Update] RFC6819 (4267) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 15:07:17 -0000 The following errata report has been held for document update for RFC6819, "OAuth 2.0 Threat Model and Security Considerations". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6819&eid=4267 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: David Gladstone Date Reported: 2015-02-09 Held by: Kathleen Moriarty (IESG) Section: 4.4.1.11 Original Text ------------- If an authorization server includes a nontrivial amount of entropy Corrected Text -------------- If an authorization server includes a trivial amount of entropy Notes ----- The threat being described outlines a scenario where too little entropy is involved; countermeasures include using non-trivial amounts of entropy. -------------------------------------- RFC6819 (draft-ietf-oauth-v2-threatmodel-08) -------------------------------------- Title : OAuth 2.0 Threat Model and Security Considerations Publication Date : January 2013 Author(s) : T. Lodderstedt, Ed., M. McGloin, P. Hunt Category : INFORMATIONAL Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Dec 8 07:13:11 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D04C1B2EF1; Tue, 8 Dec 2015 07:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VC1wOmUnIs5a; Tue, 8 Dec 2015 07:13:04 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0401B2ECD; Tue, 8 Dec 2015 07:13:04 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 296B4180094; Tue, 8 Dec 2015 07:11:02 -0800 (PST) To: torsten@lodderstedt.net, dick.hardt@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20151208151102.296B4180094@rfc-editor.org> Date: Tue, 8 Dec 2015 07:11:02 -0800 (PST) Archived-At: Cc: rfc-editor@rfc-editor.org, Kathleen.Moriarty@emc.com, iesg@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] [Errata Held for Document Update] RFC6749 (3780) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 15:13:06 -0000 The following errata report has been held for document update for RFC6749, "The OAuth 2.0 Authorization Framework". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3780 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Torsten Lodderstedt Date Reported: 2013-11-04 Held by: Kathleen Moriarty (IESG) Section: 3.2.1 Original Text ------------- A client MAY use the \\\\"client_id\\\\" request parameter to identify itself when sending requests to the token endpoint. Corrected Text -------------- A public client MAY use the \\\\"client_id\\\\" request parameter to identify itself when sending requests to the token endpoint. Notes ----- Note from AD: The provided link doesn\\'t exactly demonstrate consensus, but the change makes sense, hence this is marked \\"Hold for Document Update\\". >From Submitter: The current text may mislead confidential clients to sent their client_id in the request body in addition to their client_id and client_secret in the BASIC authz header. This leads to unnecessary duplication and ambiguities. There has been consensus on the list that the intention of this sentence was to advise _public_ clients to identity themselves towards the token endpoint in order to mitigate substitution attacks and allow for logging. Confidential clients need to authenticate anyway, this sentence should be narrowed down to public clients only. see http://www.ietf.org/mail-archive/web/oauth/current/msg12005.html This issue was discovered in the course of the OpenID Connect Interop testings. -------------------------------------- RFC6749 (draft-ietf-oauth-v2-31) -------------------------------------- Title : The OAuth 2.0 Authorization Framework Publication Date : October 2012 Author(s) : D. Hardt, Ed. Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Dec 8 07:30:01 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F881B2F24; Tue, 8 Dec 2015 07:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmlCLoUw-Whn; Tue, 8 Dec 2015 07:29:58 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 655DE1B2F1C; Tue, 8 Dec 2015 07:29:56 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0BDEB1804F5; Tue, 8 Dec 2015 07:27:54 -0800 (PST) To: eriksencosta@gmail.com, dick.hardt@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20151208152754.0BDEB1804F5@rfc-editor.org> Date: Tue, 8 Dec 2015 07:27:54 -0800 (PST) Archived-At: Cc: rfc-editor@rfc-editor.org, Kathleen.Moriarty@emc.com, iesg@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] [Errata Rejected] RFC6749 (3880) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 15:29:59 -0000 The following errata report has been rejected for RFC6749, "The OAuth 2.0 Authorization Framework". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3880 -------------------------------------- Status: Rejected Type: Technical Reported by: Eriksen Costa Date Reported: 2014-02-04 Rejected by: Kathleen Moriarty (IESG) Section: 10.16 Original Text ------------- For public clients using implicit flows, this specification does not provide any method for the client to determine what client an access token was issued to. Corrected Text -------------- For public clients using implicit flows, this specification does not provide any method for the authorization server to determine what client an access token was issued to. Notes ----- A client can only know about tokens issued to it and not for other clients. >From the WG: https://www.ietf.org/mail-archive/web/oauth/current/msg12391.html --VERIFIER NOTES-- The current text is correct, see https://www.ietf.org/mail-archive/web/oauth/current/msg12391.html -------------------------------------- RFC6749 (draft-ietf-oauth-v2-31) -------------------------------------- Title : The OAuth 2.0 Authorization Framework Publication Date : October 2012 Author(s) : D. Hardt, Ed. Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Dec 8 07:47:17 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE871B2F4A for ; Tue, 8 Dec 2015 07:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMHBU9UycYa9 for ; Tue, 8 Dec 2015 07:47:14 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3072C1B2F45 for ; Tue, 8 Dec 2015 07:47:14 -0800 (PST) Received: by wmww144 with SMTP id w144so34938487wmw.0 for ; Tue, 08 Dec 2015 07:47:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=aMy3KfHNfIszYb+j0A/dxRN4fDQAEI1Y/6NLYcoe+N4=; b=B0tQTkxFbHhFp2o9MMuPs02YCr0NRhiGarQPR2x4QE1pjGvaYV6WdHLh4PQWKCWlfu NV/3WRxo4q5zcLny7IMt0A/Va1NOVghbEB1UeM/NquIMdjmpJU2vSeL6Kb0vPHUKBO4q fAQ/oAAJ+Hb/mwsS+T2pqkbyIhs0bgrAOAEGcFRSEA3dYaPDsZ9P6Einq05XpqmwCy01 0KTbo5ZDIeeYHUnbpTsJkYuUQXL7/EX1rbqV4RVuHg7MW2KlqKJSuILTlGMU4rM8dudk IwyCOoEmMYICp9LhfjQ49N2NCCYkoHbQpaf0NQW+ziYXs4IbDrylF+6lGVlhq8xmsb2p hehQ== MIME-Version: 1.0 X-Received: by 10.194.179.162 with SMTP id dh2mr215373wjc.17.1449589632732; Tue, 08 Dec 2015 07:47:12 -0800 (PST) Received: by 10.28.52.130 with HTTP; Tue, 8 Dec 2015 07:47:12 -0800 (PST) Date: Tue, 8 Dec 2015 10:47:12 -0500 Message-ID: From: Kathleen Moriarty To: "oauth@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [OAUTH-WG] Errata 3904 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 15:47:15 -0000 Hi, I'm inclined to reject the following errata on 2 counts: error_description is already included int he registry and adding a new entry involves a 'specification required' and a review period on the email list for that registry. Should there be a specification for this? It looks the same as error_description to me, but maybe I'm missing something? Errata description: https://www.ietf.org/mail-archive/web/oauth/current/msg12519.html Section of OAuth 2.0 referenced: https://tools.ietf.org/html/rfc6749#section-11.2.2 -- Best regards, Kathleen From nobody Tue Dec 8 08:08:15 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B191B2F72 for ; Tue, 8 Dec 2015 08:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjR95byGypj8 for ; Tue, 8 Dec 2015 08:08:12 -0800 (PST) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 582BC1B2F77 for ; Tue, 8 Dec 2015 08:08:12 -0800 (PST) Received: by qgec40 with SMTP id c40so22593464qge.2 for ; Tue, 08 Dec 2015 08:08:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dbJtsJCbsENSo3ndz9aKtBCWhHksGd7oRMEmXEdYVhk=; b=EbfDxVHykA1shnmMtqp/4Bzb6H4wk34CV4ypwsbIYvTBp6xBGHk56LJTEryPvRDliD VOylvk0B+3gc1L7Bi3zVQpfPdJBZhCzh0XcjY+2201uFEAU1AjedtzW1ULTL57glAHlV C6l6CKWvNytGkYzrAWIR1uVNNXyQXSw0/VLnAEpkdNh94z+OlA2Oj90IsXM9tJ1CkeMf 6qYky8EpPZi/Q9x+KoDbXfQuxMQ9ibv3txF3+mxVP2Gu8lU5S04Q9CncIBKdu87TcfxN 7dTERR7LJqWPfSq5qEYKRj/G+ZnEOHLeD69LBm+qRm4AZl4XYXr4d6OGQnB1A3heQzHd EyhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=dbJtsJCbsENSo3ndz9aKtBCWhHksGd7oRMEmXEdYVhk=; b=eOqNfQrkRH+bRSB9F6fBBSkHIjqcPprNHdGmLF1PUrWs4cK5kcjGtbE2Ae7z5C7sQi Yw9zaBsoRUdItkBdacMeLZ3G4k6AZiAnznsHIMAjgkzmvpcJTY7N3sLNcf6VxYzPzBXe sfTMdtNrFxGioV5Unhut+WCJeViMCFzbwtenLvIBitor1a0ad252k1zz4ku2PX/UQX2N 9nfTH6QzuzcHzXP1ErhS/HA99RqxFxkY72lCi1MkMvhIkEeofW35bAFwiF+nw4G0eWqH btaq0LpuQtXjHdzKApLyO+Ai1A7KTynTLhYvQsAA3V8H5ZLGbeKz74R7kzCzEZa6jD5d 2Vfw== X-Gm-Message-State: ALoCoQlXzZ55Ox66sA1Fc9PWZiGEzDqzqsnosQ4166fZkWwVI+6aqgRJ1K05z7kh6CPFnc1g2Ro4jaN0CKbswO87CikDalMrbA== X-Received: by 10.55.25.94 with SMTP id k91mr396669qkh.45.1449590875270; Tue, 08 Dec 2015 08:07:55 -0800 (PST) Received: from [192.168.1.216] ([191.115.1.95]) by smtp.gmail.com with ESMTPSA id j106sm1796664qge.3.2015.12.08.08.07.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Dec 2015 08:07:54 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: Date: Tue, 8 Dec 2015 13:07:47 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <80D4C2AF-F089-4021-8C33-8FB10CCD83D8@ve7jtb.com> References: To: Kathleen Moriarty X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Errata 3904 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 16:08:14 -0000 It is registered in the IANA registry http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml It is properly specified as a parameter in RFC6749 For some reason in the doc it is not properly listed in the IANA = actions. I would need to go back through the diffs, perhaps it = disappeared after the IANA actions and before the RFC editors final = draft.=20 It is a bit strange, however the IANA registry is authoritative, I = don=E2=80=99t know that a missing IANA instruction is worth making a big = deal over at this point. If we update the doc we could add that back in, as apparently some = people look at that list rather than the registry. John B. > On Dec 8, 2015, at 12:47 PM, Kathleen Moriarty = wrote: >=20 > Hi, >=20 > I'm inclined to reject the following errata on 2 counts: >=20 > error_description is already included int he registry and adding a new > entry involves a 'specification required' and a review period on the > email list for that registry. >=20 > Should there be a specification for this? It looks the same as > error_description to me, but maybe I'm missing something? >=20 > Errata description: > https://www.ietf.org/mail-archive/web/oauth/current/msg12519.html >=20 > Section of OAuth 2.0 referenced: > https://tools.ietf.org/html/rfc6749#section-11.2.2 >=20 > --=20 >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Dec 8 08:14:35 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6951B2F98 for ; Tue, 8 Dec 2015 08:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wLeUGqAcx93 for ; Tue, 8 Dec 2015 08:14:32 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE6061B2F96 for ; Tue, 8 Dec 2015 08:14:31 -0800 (PST) Received: by wmvv187 with SMTP id v187so220658762wmv.1 for ; Tue, 08 Dec 2015 08:14:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WOoSqiSXArx0qsI2ChHyhg68BUg4CwrtX5PyjkCta+0=; b=EdZe1ZQ252IvdX/QsNXwWPP9A4t4T3C3Za4rBu1LRX5BhTfcHShlJnXiYrt8Rg7Ned a+Eqof/rB+VaLrG4vJpG2HcaB3HvssDYfTfuQoRfJZdqfooe4dj5chk64CDc1/nMBiQg HgKAQNqxdwZiqxZ2yu8hve8ImxU1cdrwHNKRcZ1XRZ6ZihtPHA3Dw6N6SCf4baEXRCZl OiHI48q7mEvTcRpO8f/kMbWwTxnUkaLdNli29tUlEXN1a0ivcIMdNHKNKL0S2G9tu2eX dPxx5hx/+OrQSI2eHY/Y8b66Yz9cFmti++3FQhG1qW1CwVbxDgotnJ5MeWdYFbn+NCKv bHcw== MIME-Version: 1.0 X-Received: by 10.194.179.162 with SMTP id dh2mr372198wjc.17.1449591270391; Tue, 08 Dec 2015 08:14:30 -0800 (PST) Received: by 10.28.52.130 with HTTP; Tue, 8 Dec 2015 08:14:30 -0800 (PST) In-Reply-To: <80D4C2AF-F089-4021-8C33-8FB10CCD83D8@ve7jtb.com> References: <80D4C2AF-F089-4021-8C33-8FB10CCD83D8@ve7jtb.com> Date: Tue, 8 Dec 2015 11:14:30 -0500 Message-ID: From: Kathleen Moriarty To: John Bradley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Errata 3904 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 16:14:34 -0000 On Tue, Dec 8, 2015 at 11:07 AM, John Bradley wrote: > It is registered in the IANA registry > http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml > > It is properly specified as a parameter in RFC6749 > > For some reason in the doc it is not properly listed in the IANA actions.= I would need to go back through the diffs, perhaps it disappeared after t= he IANA actions and before the RFC editors final draft. > > It is a bit strange, however the IANA registry is authoritative, I don=E2= =80=99t know that a missing IANA instruction is worth making a big deal ove= r at this point. > > If we update the doc we could add that back in, as apparently some people= look at that list rather than the registry. Thanks, John. I should have looked at the registry! I'll mark this as verified and note that it is already in the registry. I'll put it down as editorial since the registry is normative. Thanks! Kathleen > > John B. > >> On Dec 8, 2015, at 12:47 PM, Kathleen Moriarty wrote: >> >> Hi, >> >> I'm inclined to reject the following errata on 2 counts: >> >> error_description is already included int he registry and adding a new >> entry involves a 'specification required' and a review period on the >> email list for that registry. >> >> Should there be a specification for this? It looks the same as >> error_description to me, but maybe I'm missing something? >> >> Errata description: >> https://www.ietf.org/mail-archive/web/oauth/current/msg12519.html >> >> Section of OAuth 2.0 referenced: >> https://tools.ietf.org/html/rfc6749#section-11.2.2 >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > --=20 Best regards, Kathleen From nobody Tue Dec 8 08:16:20 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28761B2F96; Tue, 8 Dec 2015 08:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UetYG0qlEYaj; Tue, 8 Dec 2015 08:16:14 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 429DD1B2F98; Tue, 8 Dec 2015 08:16:10 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C341718019D; Tue, 8 Dec 2015 08:14:07 -0800 (PST) To: takahiko.kawasaki@neovisionaries.com, dick.hardt@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20151208161407.C341718019D@rfc-editor.org> Date: Tue, 8 Dec 2015 08:14:07 -0800 (PST) Archived-At: Cc: rfc-editor@rfc-editor.org, Kathleen.Moriarty@emc.com, iesg@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] [Errata Verified] RFC6749 (3904) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 16:16:15 -0000 The following errata report has been verified for RFC6749, "The OAuth 2.0 Authorization Framework". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3904 -------------------------------------- Status: Verified Type: Editorial Reported by: Takahiko Kawasaki Date Reported: 2014-03-01 Verified by: Kathleen Moriarty (IESG) Section: 11.2.2. Original Text ------------- Corrected Text -------------- o Parameter name: error o Parameter usage location: authorization response, token response o Change controller: IETF o Specification document(s): RFC 6749 Notes ----- \\\\"error\\\\" is missing and should be added to the list of Initial Registry Contents of OAuth Parameters Registry. AD note: This is in the normative registry, although it doesn\\'t appear in the final published RFC. The WG suspects there was a mistake that removed it from RFC6749 prior to final publication. I\\'ve marked this as editorial since the IANA registry is normative, but also as verified. -------------------------------------- RFC6749 (draft-ietf-oauth-v2-31) -------------------------------------- Title : The OAuth 2.0 Authorization Framework Publication Date : October 2012 Author(s) : D. Hardt, Ed. Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Dec 8 08:20:46 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7508B1B2FAB for ; Tue, 8 Dec 2015 08:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bExmwcY8481 for ; Tue, 8 Dec 2015 08:20:43 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4842C1B2F77 for ; Tue, 8 Dec 2015 08:20:43 -0800 (PST) Received: by wmvv187 with SMTP id v187so220951784wmv.1 for ; Tue, 08 Dec 2015 08:20:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=f1JK0UjON7MvFclXuAtEmpTR4rUhMED42Z9snKg+ETA=; b=VBZ6hIZvkTj/s/ELbqiOl5m1xTJC8aX2AG7pkfl6Fhg47btDSI69LYfbM88cRS1pcE 9JTrg1n3hUH4BH59CfBP/LwWXz30Q+AahZInuQ2OYLjaBlG6T5eGMNXelCCqUfADeSQ+ ipotkOFO9F2lLPREKJqX6W27Gwbm6SvW4o6uMkCwf+hZrbcwJ3oUMUzgPjF7ij4KFy5i 6c8gN6PlugT+rZEmRDzzsKFKEMuVE+wEG1kD6TrNv0HEXY/iHuVdidAaKIl2jA+wdgKi tD7GrR6KHMdIPrt9Old70pEDdQTUGBZsbzogXHDXN8SdZlabp73VnsN4rQR8psK1nnQf MoDg== MIME-Version: 1.0 X-Received: by 10.194.179.162 with SMTP id dh2mr408481wjc.17.1449591641931; Tue, 08 Dec 2015 08:20:41 -0800 (PST) Received: by 10.28.52.130 with HTTP; Tue, 8 Dec 2015 08:20:41 -0800 (PST) Date: Tue, 8 Dec 2015 11:20:41 -0500 Message-ID: From: Kathleen Moriarty To: "oauth@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [OAUTH-WG] errata id 4206 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 16:20:45 -0000 Hi, What do we do with the following errata, I don;t see any prior list responses: https://www.ietf.org/mail-archive/web/oauth/current/msg14033.html Thank you! -- Best regards, Kathleen From nobody Tue Dec 8 09:02:04 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14691A007A for ; Tue, 8 Dec 2015 09:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6ZvyHBG89SX for ; Tue, 8 Dec 2015 09:02:00 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 893241A0052 for ; Tue, 8 Dec 2015 09:02:00 -0800 (PST) Received: by qgeb1 with SMTP id b1so25350387qge.1 for ; Tue, 08 Dec 2015 09:01:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Y2jk0iDAz1WrBZRybRO46zihyFqrLQKTZjxwOdErnCM=; b=PLvO+iQUPc8qCII7VuBR/02Qvs6G6V7fx2jrKJnBHDhUUl1X8ZF1neSIzbuTi/U8HL nELqFFGRTkPL/I+Y6qtzwiQljcOR0LpBOB7+kZD9xrF4X8x4SzUPQEb91usC+UkPfjbx w1FEmp64ODJHEk85DKv+UUtYp1gku8/v1BdMLKdXNSrNFY6l9lJL2ykdfBjKOl5EvcgU Q0MNR5Ze0rU0+HpD6XhDRMmpU1zp9T6I7oABlwakwuqO6gKCIcpXOOvkrCduK8dsyp8W l6O+YiLGbF3j2jMkwDRA1/iYx5Zz8Zb+/77Nzv+KhZ8yd4xXuJ5FgL5tnimR6XgqgIBl KNtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Y2jk0iDAz1WrBZRybRO46zihyFqrLQKTZjxwOdErnCM=; b=PGK4oPrBmY47+fSBXih2T50VZEnbH0mKjWw38G93y6F4fmpnvirZn1W3NHDl/Vgrk7 Jq7bGBnxGuGuT104M6cIQY77RafJmvmVwCDG4VbKYGRdziVRpMI/WK+mftzYZGFtjZf1 WlIfeFalNmCowpmPD6fCd4g88OXFpYin3d9+GFq0++ey60gXFgzYlRaWit+hZHXo7BQQ J382RS4ihwLJU0bYI1XpLmgNeW4H2VLJxD9rwaM36fHNMlWZ3+UHmQLUzTLvJi3zIPEz RPeyPcG+PwltGZdgUPPZSWarptAR82ZHH9XRee+fV6ZiuVvW19OJOEtmMRa+ghbPFCHu ps1g== X-Gm-Message-State: ALoCoQl9aV8xvON/mYdrhlrG7e1kkiuOQNtvF27lmT4wVIVpvPWIcA5WbQ0SlG7cHTq72gO5HzkA96KDxXZyHSiCvrDR7YY62Q== X-Received: by 10.140.40.38 with SMTP id w35mr855473qgw.52.1449594108747; Tue, 08 Dec 2015 09:01:48 -0800 (PST) Received: from [192.168.1.216] ([191.115.1.95]) by smtp.gmail.com with ESMTPSA id o33sm1894404qkh.24.2015.12.08.09.01.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Dec 2015 09:01:47 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: Date: Tue, 8 Dec 2015 14:01:41 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0068E079-5B7B-4DB8-9AFF-F4C7E22D8305@ve7jtb.com> References: To: Kathleen Moriarty X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] errata id 4206 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 17:02:02 -0000 The normative text in Sec 4.1.3 is correct. redirect_uri REQUIRED, if the "redirect_uri" parameter was included in the authorization request as described in=20 Section 4.1.1, and their values MUST be identical. The example is arguably not the best worded. =20 =46rom the servers point of view the redirect_uri supplied in step A is = identical to the one it uses in step C. =46rom the client=E2=80=99s point of view they receive a authorization = response back on the redirect URI with additional parameters,=20 so the redirect_uri value is only part of the response URI. I think his wording is better, but what is there is not strictly = speaking wrong. =20 It is in non normative text, and the normative text is correct. I would mark it as editorial. John B. > On Dec 8, 2015, at 1:20 PM, Kathleen Moriarty = wrote: >=20 > Hi, >=20 > What do we do with the following errata, I don;t see any prior list = responses: >=20 > https://www.ietf.org/mail-archive/web/oauth/current/msg14033.html >=20 > Thank you! >=20 > --=20 >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Dec 8 09:04:26 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26021A0069 for ; Tue, 8 Dec 2015 09:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DszJTDmrdK_n for ; Tue, 8 Dec 2015 09:04:24 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C02A1A0052 for ; Tue, 8 Dec 2015 09:04:24 -0800 (PST) Received: by iofh3 with SMTP id h3so30743332iof.3 for ; Tue, 08 Dec 2015 09:04:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aHa5WrQi8UoKzMSdXlZQVmvWQ8L3TcSlwEvYG2in/cY=; b=Q1WWz49DMuNQwT85EPfIiNxec2dTkONAXn94jwBsu6OYQrSB2ihqcs+SY4BzJqlh7V 4SViPi1KOEeN4Fp7AT1VEGiGxbY+aPcU9ePBh/eAyMR6f3v79kJ12b/EbRKoD4rphusT hnqif7zhxfBqgvZnxowC9yPcj7KcghDi+RxFs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=aHa5WrQi8UoKzMSdXlZQVmvWQ8L3TcSlwEvYG2in/cY=; b=llpS2z+L753o6X6wQT59c0ILvM2D7Uc556KA/bCaB/AKL/4po0rWcB4sU/enydPZGH NiEETKSjHthU2d9cDhGMCBt4lMs4i6erdACP0GvFlvdtKCEzjQ3fpb1IqawKTDFg12Er X8SQgCfzQgRs7PpJs9Q+UAIpee4t1uytO6b/fKMpYWLstPqKwIqWclyBfHBVR9bARsKu CVnCdbFz6AJMixuc7RROKirV6N/mMjeY3Q/HTDcWf8ZvHRP6ehLckvw61W4kJVIl7nVx z1AhSxwHaAFWaA6TeYeqr0Xk1R7jNaQOVfb/2TLhebOPIJT3zhJyxzI3g4koM3Bg3BNY r7LQ== X-Gm-Message-State: ALoCoQku3z+eyJkDmrHYMRorkwe9lPzgC9O15LLp3EAB5feNSpQW4buxmud7nBiP9bwzPmdUYuPy9zvhjbDO2DjxNetqz7Ng1JYLD13lba3YRWS+4wzSSc4= X-Received: by 10.107.36.208 with SMTP id k199mr1026251iok.147.1449594263427; Tue, 08 Dec 2015 09:04:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.23.133 with HTTP; Tue, 8 Dec 2015 09:03:53 -0800 (PST) In-Reply-To: <0068E079-5B7B-4DB8-9AFF-F4C7E22D8305@ve7jtb.com> References: <0068E079-5B7B-4DB8-9AFF-F4C7E22D8305@ve7jtb.com> From: Brian Campbell Date: Tue, 8 Dec 2015 10:03:53 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a11405f0423f85c052665f7a1 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] errata id 4206 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 17:04:25 -0000 --001a11405f0423f85c052665f7a1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 On Tue, Dec 8, 2015 at 10:01 AM, John Bradley wrote: > The normative text in Sec 4.1.3 is correct. > > redirect_uri > REQUIRED, if the "redirect_uri" parameter was included in the > authorization request as described in > Section 4.1.1, and their values MUST be identical. > > The example is arguably not the best worded. > > From the servers point of view the redirect_uri supplied in step A is > identical to the one it uses in step C. > > From the client=E2=80=99s point of view they receive a authorization resp= onse back > on the redirect URI with additional parameters, > so the redirect_uri value is only part of the response URI. > > I think his wording is better, but what is there is not strictly speaking > wrong. > > It is in non normative text, and the normative text is correct. > > I would mark it as editorial. > > John B. > > > On Dec 8, 2015, at 1:20 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > > > Hi, > > > > What do we do with the following errata, I don;t see any prior list > responses: > > > > https://www.ietf.org/mail-archive/web/oauth/current/msg14033.html > > > > Thank you! > > > > -- > > > > Best regards, > > Kathleen > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11405f0423f85c052665f7a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

On Tue, Dec 8, 2015 at 10:01 AM, John Bradley <ve7jtb@ve7jtb.= com> wrote:
The normative t= ext in Sec 4.1.3 is correct.

redirect_uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0REQUIRED, if the "redirect_uri"= parameter was included in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0authorization request as described in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 4.1.1, and their values MUST be i= dentical.

The example is arguably not the best worded.

>From the servers point of view the redirect_uri supplied in step A is ident= ical to the one it uses in step C.

>From the client=E2=80=99s point of view they receive a authorization respon= se back on the redirect URI with additional parameters,
so the redirect_uri value is only part of the response URI.

I think his wording is better, but what is there is not strictly speaking w= rong.

It is in non normative text, and the normative text is correct.

I would mark it as editorial.

John B.

> On Dec 8, 2015, at 1:20 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wr= ote:
>
> Hi,
>
> What do we do with the following errata, I don;t see any prior list re= sponses:
>
> https://www.ietf.org/mail-arch= ive/web/oauth/current/msg14033.html
>
> Thank you!
>
> --
>
> Best regards,
> Kathleen
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--001a11405f0423f85c052665f7a1-- From nobody Tue Dec 8 09:10:47 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE4F1A00FE for ; Tue, 8 Dec 2015 09:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJ9iXvIM6XDX for ; Tue, 8 Dec 2015 09:10:44 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782B71A00FC for ; Tue, 8 Dec 2015 09:10:44 -0800 (PST) Received: by wmww144 with SMTP id w144so38266220wmw.0 for ; Tue, 08 Dec 2015 09:10:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lt9eP70QBFmbv1tyHHG+DrH+lZw6+216L/K5VP9noys=; b=R6xBZkFd41AznjDlhfwuPJntJ4Au8vFb2UC4nCrEaKKeZ5ab9/sVPUOl86OIlK3WZb xKTHtaILouKLHhTcGmuWAF2LJ5P2DNs8C8jSajE5HyD02Ldfhjp8w4EY1Qm6f9dODBDC mPpMmK+aBJSKwTM6QkgTwgKNNvFqJ0EMn4rP9nHhHfW9XBfX0SbbDemioVcYRRuYLYR4 DjNF6mmvTeujVNgVKXgCaKsMMFD66hArfdLchoq5h8zZvYPd1BfRTgMI99G8+h853bBh r3FSL49FLP8y6anAFCcXfwoqUrYBVrkPq5T1UANJNJ5KkJnHd96zM7u6A0xj+E4LVdy2 sJ4A== MIME-Version: 1.0 X-Received: by 10.194.179.162 with SMTP id dh2mr680111wjc.17.1449594642906; Tue, 08 Dec 2015 09:10:42 -0800 (PST) Received: by 10.28.52.130 with HTTP; Tue, 8 Dec 2015 09:10:42 -0800 (PST) In-Reply-To: References: <0068E079-5B7B-4DB8-9AFF-F4C7E22D8305@ve7jtb.com> Date: Tue, 8 Dec 2015 12:10:42 -0500 Message-ID: From: Kathleen Moriarty To: Brian Campbell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] errata id 4206 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 17:10:46 -0000 Thank you, both! I'll note this as editorial and will also note that the URI is the same in A and C, but that the wording is better, hence editorial. Kathleen On Tue, Dec 8, 2015 at 12:03 PM, Brian Campbell wrote: > +1 > > On Tue, Dec 8, 2015 at 10:01 AM, John Bradley wrote: >> >> The normative text in Sec 4.1.3 is correct. >> >> redirect_uri >> REQUIRED, if the "redirect_uri" parameter was included in the >> authorization request as described in >> Section 4.1.1, and their values MUST be identical. >> >> The example is arguably not the best worded. >> >> From the servers point of view the redirect_uri supplied in step A is >> identical to the one it uses in step C. >> >> From the client=E2=80=99s point of view they receive a authorization res= ponse back >> on the redirect URI with additional parameters, >> so the redirect_uri value is only part of the response URI. >> >> I think his wording is better, but what is there is not strictly speakin= g >> wrong. >> >> It is in non normative text, and the normative text is correct. >> >> I would mark it as editorial. >> >> John B. >> >> > On Dec 8, 2015, at 1:20 PM, Kathleen Moriarty >> > wrote: >> > >> > Hi, >> > >> > What do we do with the following errata, I don;t see any prior list >> > responses: >> > >> > https://www.ietf.org/mail-archive/web/oauth/current/msg14033.html >> > >> > Thank you! >> > >> > -- >> > >> > Best regards, >> > Kathleen >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > --=20 Best regards, Kathleen From nobody Tue Dec 8 09:14:21 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2491A0137; Tue, 8 Dec 2015 09:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNkJHDgeBepX; Tue, 8 Dec 2015 09:14:18 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9391B1A0102; Tue, 8 Dec 2015 09:14:18 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 011411804F5; Tue, 8 Dec 2015 09:12:15 -0800 (PST) To: alex@kempgen.de, dick.hardt@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20151208171216.011411804F5@rfc-editor.org> Date: Tue, 8 Dec 2015 09:12:16 -0800 (PST) Archived-At: Cc: rfc-editor@rfc-editor.org, Kathleen.Moriarty@emc.com, iesg@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] [Errata Held for Document Update] RFC6749 (4206) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 17:14:20 -0000 The following errata report has been held for document update for RFC6749, "The OAuth 2.0 Authorization Framework". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=4206 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Alexander Kempgen Date Reported: 2014-12-23 Held by: Kathleen Moriarty (IESG) Section: 4.1 Original Text ------------- (E) The authorization server authenticates the client, validates the authorization code, and ensures that the redirection URI received matches the URI used to redirect the client in step (C). If valid, the authorization server responds back with an access token and, optionally, a refresh token. Corrected Text -------------- (E) The authorization server authenticates the client, validates the authorization code, and ensures that the redirection URI received matches the redirection URI provided by the client in step (A). If valid, the authorization server responds back with an access token and, optionally, a refresh token. Notes ----- AD & WG notes: The wording is better, so this is accepted, but it does mean the same thing. The URI in A and C are the same. See https://www.ietf.org/mail-archive/web/oauth/current/msg15277.html and responses. Submitter notes: As written in section 4.1.3, the redirection URI in the access token request must match the redirection URI provided by the client in the authorization request (4.1.1). The URI used to redirect the user agent to the client in step (C) is actually different from this URI, as it contains the additional query parameters \\\\\\\\\\\\\\\\"code\\\\\\\\\\\\\\\\" and \\\\\\\\\\\\\\\\"state\\\\\\\\\\\\\\\\". Affects the same sentence as Errata ID: 3500. -------------------------------------- RFC6749 (draft-ietf-oauth-v2-31) -------------------------------------- Title : The OAuth 2.0 Authorization Framework Publication Date : October 2012 Author(s) : D. Hardt, Ed. Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Dec 8 11:17:35 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107611A1B98; Tue, 8 Dec 2015 11:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izPJibVfYrZq; Tue, 8 Dec 2015 11:17:29 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0747.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:747]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 300DD1A1B87; Tue, 8 Dec 2015 11:17:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JLJaz/p5Mxeigkb//suzeXVDvXBhe8o3td2nkyp74Ms=; b=RjIrOQsI8WhZKwKZBJokvuBuzY5o1/NJQzid0CEckvWUzwmjGRcFSKCpumkfD1J1uGRh/k5FWIioZQCC8vQkoYKkNvVKxmUsYsgENao2BBwFyFiWwAZph6kYtDvInsecbFWJ5W61A+NUAavOh3Jx1ZovO4WxvWC4PqigEz329Uw= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 8 Dec 2015 19:17:04 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Tue, 8 Dec 2015 19:17:03 +0000 From: Mike Jones To: RFC Errata System , "takahiko.kawasaki@neovisionaries.com" , "dick.hardt@gmail.com" Thread-Topic: [OAUTH-WG] [Errata Verified] RFC6749 (3904) Thread-Index: AQHRMdPI1sTE4BHtsUmsloqbYQLOdp7BdbTQ Date: Tue, 8 Dec 2015 19:17:03 +0000 Message-ID: References: <20151208161407.C341718019D@rfc-editor.org> In-Reply-To: <20151208161407.C341718019D@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:5::1cd] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:M7nusLGqmO+tp/QIZ+Gzq75SBYrIOuNYrDusiidDExCFehcHSneRtA0F1hS2DvstdMG1mbIy4EhwPPzuFkIPYCn4WMFxZbtUWXWiKrG/gZraX23f4iAP0KASiRX9whuRWUpDiFnwzYlfOo8qTfbpAQ==; 24:Nn033Kdm0+xg0QGXZ/D9ZbdXPxeEk0F9fP0E1nK2op0R5DR+OAEe3Z3seB5pzRZggnoxq5QyUe3Z+/QKwTv6Vc+3F/EMr8SXO9tvfS6Y90M= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278771537138765); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0784C803FD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(377454003)(13464003)(377424004)(86612001)(1096002)(2201001)(81156007)(5002640100001)(40100003)(10710500006)(92566002)(2501003)(5004730100002)(76576001)(102836003)(74316001)(586003)(5008740100001)(6116002)(10290500002)(33656002)(106356001)(122556002)(5005710100001)(105586002)(16799955002)(5003600100002)(15188155005)(101416001)(10090500001)(1220700001)(106116001)(54356999)(87936001)(2420400006)(19580405001)(19580395003)(50986999)(7110500001)(189998001)(76176999)(86362001)(8990500004)(5001960100002)(2950100001)(77096005)(15975445007)(99286002)(97736004)(5001770100001)(2900100001)(10400500002)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2015 19:17:03.7822 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Cc: "Kathleen.Moriarty@emc.com" , "iesg@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [Errata Verified] RFC6749 (3904) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 19:17:34 -0000 For what it's worth, I had this added to the IANA registry quite some time = ago, which you can see at http://www.iana.org/assignments/oauth-parameters/= oauth-parameters.xhtml#parameters. So the registry is correct. -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of RFC Errata System Sent: Tuesday, December 08, 2015 8:14 AM To: takahiko.kawasaki@neovisionaries.com; dick.hardt@gmail.com Cc: rfc-editor@rfc-editor.org; Kathleen.Moriarty@emc.com; iesg@ietf.org; oa= uth@ietf.org Subject: [OAUTH-WG] [Errata Verified] RFC6749 (3904) The following errata report has been verified for RFC6749, "The OAuth 2.0 A= uthorization Framework".=20 -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D6749&eid=3D3904 -------------------------------------- Status: Verified Type: Editorial Reported by: Takahiko Kawasaki Date Reported: 2014-03-01 Verified by: Kathleen Moriarty (IESG) Section: 11.2.2. Original Text ------------- Corrected Text -------------- o Parameter name: error o Parameter usage location: authorization response, token response o Change controller: IETF o Specification document(s): RFC 6749 Notes ----- \\\\"error\\\\" is missing and should be added to the list of Initial Regis= try Contents of OAuth Parameters Registry. AD note: This is in the normative registry, although it doesn\\'t appear in= the final published RFC. The WG suspects there was a mistake that removed= it from RFC6749 prior to final publication. I\\'ve marked this as editori= al since the IANA registry is normative, but also as verified. -------------------------------------- RFC6749 (draft-ietf-oauth-v2-31) -------------------------------------- Title : The OAuth 2.0 Authorization Framework Publication Date : October 2012 Author(s) : D. Hardt, Ed. Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Dec 8 11:42:22 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6191A1C06; Tue, 8 Dec 2015 11:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3ojR05luYUm; Tue, 8 Dec 2015 11:42:13 -0800 (PST) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 882991A1E0B; Tue, 8 Dec 2015 11:42:13 -0800 (PST) Received: by qgeb1 with SMTP id b1so33155851qge.1; Tue, 08 Dec 2015 11:42:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BwHtSJC9uv45daTQsQ6P3kS285FibQE5tSLhvRRjY2U=; b=oNN29k3g8vwlQXmKUWu6N5yrySp3WGenKfMNUClUmPPcLW9hE9u2c6hepgA3Ux3eEL OGCRx9b5PbqmIRsc/gKbdwkQnPRZUDjiGZ1O0x8VuxjKD//0g1xP9maUhh8bqO+IiSyq 25KB5MWdIKWxlh9P2l5LJmHRysr/FEmOs/xmHbN2/uWCKIFTGvnHOpO1vcfrIt6FjtB/ r9fA39sqTdrZaH2MUN0vKcozvjCJ2k2/kf6+9PjqaZAIQRPHvTDiYFKFYlQ1RMA3qUSI l+Sjx0CB0jYSOwcoyWa16t1VDP288xfBZkiulZUhHFDVIvouO97BJoggH/UcWmYPFGvx CmDw== X-Received: by 10.55.79.86 with SMTP id d83mr2052337qkb.22.1449603732559; Tue, 08 Dec 2015 11:42:12 -0800 (PST) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by smtp.gmail.com with ESMTPSA id d130sm2170464qkb.33.2015.12.08.11.42.10 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Dec 2015 11:42:11 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: Date: Tue, 8 Dec 2015 14:42:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0DF01EC1-2D81-40BD-ABD1-FD6C20E6E03C@gmail.com> References: <20151208161407.C341718019D@rfc-editor.org> To: Mike Jones Archived-At: Cc: "takahiko.kawasaki@neovisionaries.com" , "iesg@ietf.org" , RFC Errata System , "Kathleen.Moriarty@emc.com" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [Errata Verified] RFC6749 (3904) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 19:42:15 -0000 Thanks, Mike! Sent from my iPhone > On Dec 8, 2015, at 2:17 PM, Mike Jones wrote= : >=20 > For what it's worth, I had this added to the IANA registry quite some time= ago, which you can see at http://www.iana.org/assignments/oauth-parameters/= oauth-parameters.xhtml#parameters. So the registry is correct. >=20 > -- Mike >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of RFC Errata System= > Sent: Tuesday, December 08, 2015 8:14 AM > To: takahiko.kawasaki@neovisionaries.com; dick.hardt@gmail.com > Cc: rfc-editor@rfc-editor.org; Kathleen.Moriarty@emc.com; iesg@ietf.org; o= auth@ietf.org > Subject: [OAUTH-WG] [Errata Verified] RFC6749 (3904) >=20 > The following errata report has been verified for RFC6749, "The OAuth 2.0 A= uthorization Framework".=20 >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6749&eid=3D3904 >=20 > -------------------------------------- > Status: Verified > Type: Editorial >=20 > Reported by: Takahiko Kawasaki > Date Reported: 2014-03-01 > Verified by: Kathleen Moriarty (IESG) >=20 > Section: 11.2.2. >=20 > Original Text > ------------- >=20 >=20 > Corrected Text > -------------- > o Parameter name: error > o Parameter usage location: authorization response, token response > o Change controller: IETF > o Specification document(s): RFC 6749 >=20 >=20 > Notes > ----- > \\\\"error\\\\" is missing and should be added to the list of Initial Regi= stry Contents of OAuth Parameters Registry. >=20 > AD note: This is in the normative registry, although it doesn\\'t appear i= n the final published RFC. The WG suspects there was a mistake that removed= it from RFC6749 prior to final publication. I\\'ve marked this as editoria= l since the IANA registry is normative, but also as verified. >=20 > -------------------------------------- > RFC6749 (draft-ietf-oauth-v2-31) > -------------------------------------- > Title : The OAuth 2.0 Authorization Framework > Publication Date : October 2012 > Author(s) : D. Hardt, Ed. > Category : PROPOSED STANDARD > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From nobody Sun Dec 13 12:43:16 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64901A0169 for ; Sun, 13 Dec 2015 12:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.449 X-Spam-Level: X-Spam-Status: No, score=0.449 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRuWqmps7p77 for ; Sun, 13 Dec 2015 12:43:11 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2378D1A0108 for ; Sun, 13 Dec 2015 12:43:10 -0800 (PST) Received: from [79.253.5.21] (helo=[192.168.71.102]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1a8DU3-0006po-6W; Sun, 13 Dec 2015 21:43:07 +0100 To: Mike Jones , "oauth@ietf.org" , Nat Sakimura , John Bradley References: From: Torsten Lodderstedt Message-ID: <566DD856.1010603@lodderstedt.net> Date: Sun, 13 Dec 2015 21:43:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090109030705090804030300" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] OAuth Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2015 20:43:14 -0000 This is a multi-part message in MIME format. --------------090109030705090804030300 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Mike, Nat, John, thanks for starting this work. It seems you assume the AS can always be discoverd using the user id of the resource owner. I think the underlying assumption is resource servers accept access token of different (any?) user specific AS (and OP)? From my perspective, RSs nowadays typically trust _the_ AS of their security domain/ecosystem and all resource owners need to have an user account with this particular AS. So I would assume the process to start at the RS. We potentially need to cover for both cases. What do you think? best regards, Torsten. Am 26.11.2015 um 00:37 schrieb Mike Jones: > > I’m pleased to announce that Nat Sakimura, John Bradley, and I have > created an OAuth 2.0 Discovery specification. This fills a hole in > the current OAuth specification set that is necessary to achieve > interoperability. Indeed, the Interoperability section of OAuth 2.0 > states: > > In addition, this specification leaves a few required components > partially or fully undefined (e.g., client registration, authorization > server capabilities, endpoint discovery). Without these components, > clients must be manually and specifically configured against a > specific authorization server and resource server in order to > interoperate. > This framework was designed with the clear expectation that future > work will define prescriptive profiles and extensions necessary to > achieve full web-scale interoperability. > > This specification enables discovery of both endpoint locations and > authorization server capabilities. > > This specification is based upon the already widely deployed OpenID > Connect Discovery 1.0 > > specification and is compatible with it, by design. The OAuth > Discovery spec removes the portions of OpenID Connect Discovery that > are OpenID specific and adds metadata values for Revocation and > Introspection endpoints. It also maps OpenID concepts, such as OpenID > Provider, Relying Party, End-User, and Issuer to their OAuth > underpinnings, respectively Authorization Server, Client, Resource > Owner, and the newly introduced Configuration Information Location. > Some identifiers with names that appear to be OpenID specific were > retained for compatibility purposes; despite the reuse of these > identifiers that appear to be OpenID specific, their usage in this > specification is actually referring to general OAuth 2.0 features that > are not specific to OpenID Connect. > > The specification is available at: > > ·http://tools.ietf.org/html/draft-jones-oauth-discovery-00 > > An HTML-formatted version is also available at: > > ·http://self-issued.info/docs/draft-jones-oauth-discovery-00.html > > -- Mike > > P.S. This note was also posted at http://self-issued.info/?p=1496 > and as @selfissued > . > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------090109030705090804030300 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Mike, Nat, John,

thanks for starting this work.

It seems you assume the AS can always be discoverd using the user id of the resource owner. I think the underlying assumption is resource servers accept access token of different (any?) user specific AS (and OP)? From my perspective, RSs nowadays typically trust _the_ AS of their security domain/ecosystem and all resource owners need to have an user account with this particular AS. So I would assume the process to start at the RS. We potentially need to cover for both cases.

What do you think?

best regards,
Torsten.

Am 26.11.2015 um 00:37 schrieb Mike Jones:

I’m pleased to announce that Nat Sakimura, John Bradley, and I have created an OAuth 2.0 Discovery specification.  This fills a hole in the current OAuth specification set that is necessary to achieve interoperability.  Indeed, the Interoperability section of OAuth 2.0 states:

In addition, this specification leaves a few required components partially or fully undefined (e.g., client registration, authorization server capabilities, endpoint discovery).  Without these components, clients must be manually and specifically configured against a specific authorization server and resource server in order to interoperate.
 
This framework was designed with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability.

 

This specification enables discovery of both endpoint locations and authorization server capabilities.

 

This specification is based upon the already widely deployed OpenID Connect Discovery 1.0 specification and is compatible with it, by design.  The OAuth Discovery spec removes the portions of OpenID Connect Discovery that are OpenID specific and adds metadata values for Revocation and Introspection endpoints.  It also maps OpenID concepts, such as OpenID Provider, Relying Party, End-User, and Issuer to their OAuth underpinnings, respectively Authorization Server, Client, Resource Owner, and the newly introduced Configuration Information Location.  Some identifiers with names that appear to be OpenID specific were retained for compatibility purposes; despite the reuse of these identifiers that appear to be OpenID specific, their usage in this specification is actually referring to general OAuth 2.0 features that are not specific to OpenID Connect.

 

The specification is available at:

·         http://tools.ietf.org/html/draft-jones-oauth-discovery-00

 

An HTML-formatted version is also available at:

·         http://self-issued.info/docs/draft-jones-oauth-discovery-00.html

 

                                                                -- Mike

 

P.S.  This note was also posted at http://self-issued.info/?p=1496 and as @selfissued.



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------090109030705090804030300-- From nobody Sun Dec 13 12:50:29 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B121A02F1 for ; Sun, 13 Dec 2015 12:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9rQkRrQcn0g for ; Sun, 13 Dec 2015 12:50:26 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012D21A0040 for ; Sun, 13 Dec 2015 12:50:25 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tBDKoNxF023607 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 13 Dec 2015 20:50:23 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tBDKoNbQ029314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 13 Dec 2015 20:50:23 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tBDKoL8K005641; Sun, 13 Dec 2015 20:50:22 GMT Received: from [10.20.218.152] (/204.239.250.1) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 13 Dec 2015 12:50:21 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-497688CC-6A53-4CCB-8956-379E164F97B1 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (13C75) In-Reply-To: <566DD856.1010603@lodderstedt.net> Date: Sun, 13 Dec 2015 12:50:18 -0800 Content-Transfer-Encoding: 7bit Message-Id: <36ECADAA-7A6F-43D5-9429-A7BDAFA0CCAC@oracle.com> References: <566DD856.1010603@lodderstedt.net> To: Torsten Lodderstedt X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2015 20:50:29 -0000 --Apple-Mail-497688CC-6A53-4CCB-8956-379E164F97B1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1. Good observation.=20 Phil > On Dec 13, 2015, at 12:43, Torsten Lodderstedt w= rote: >=20 > Hi Mike, Nat, John, >=20 > thanks for starting this work.=20 >=20 > It seems you assume the AS can always be discoverd using the user id of th= e resource owner. I think the underlying assumption is resource servers acce= pt access token of different (any?) user specific AS (and OP)? =46rom my per= spective, RSs nowadays typically trust _the_ AS of their security domain/eco= system and all resource owners need to have an user account with this partic= ular AS. So I would assume the process to start at the RS. We potentially ne= ed to cover for both cases.=20 >=20 > What do you think? >=20 > best regards, > Torsten. >=20 >> Am 26.11.2015 um 00:37 schrieb Mike Jones: >> I=E2=80=99m pleased to announce that Nat Sakimura, John Bradley, and I ha= ve created an OAuth 2.0 Discovery specification. This fills a hole in the c= urrent OAuth specification set that is necessary to achieve interoperability= . Indeed, the Interoperability section of OAuth 2.0 states: >> In addition, this specification leaves a few required components partiall= y or fully undefined (e.g., client registration, authorization server capabi= lities, endpoint discovery). Without these components, clients must be manu= ally and specifically configured against a specific authorization server and= resource server in order to interoperate. >> =20 >> This framework was designed with the clear expectation that future work w= ill define prescriptive profiles and extensions necessary to achieve full we= b-scale interoperability. >> =20 >> This specification enables discovery of both endpoint locations and autho= rization server capabilities. >> =20 >> This specification is based upon the already widely deployed OpenID Conne= ct Discovery 1.0 specification and is compatible with it, by design. The OA= uth Discovery spec removes the portions of OpenID Connect Discovery that are= OpenID specific and adds metadata values for Revocation and Introspection e= ndpoints. It also maps OpenID concepts, such as OpenID Provider, Relying Pa= rty, End-User, and Issuer to their OAuth underpinnings, respectively Authori= zation Server, Client, Resource Owner, and the newly introduced Configuratio= n Information Location. Some identifiers with names that appear to be OpenI= D specific were retained for compatibility purposes; despite the reuse of th= ese identifiers that appear to be OpenID specific, their usage in this speci= fication is actually referring to general OAuth 2.0 features that are not sp= ecific to OpenID Connect. >> =20 >> The specification is available at: >> =C2=B7 http://tools.ietf.org/html/draft-jones-oauth-discovery-00 >> =20 >> An HTML-formatted version is also available at: >> =C2=B7 http://self-issued.info/docs/draft-jones-oauth-discovery-0= 0.html >> =20 >> -- Mike >> =20 >> P.S. This note was also posted at http://self-issued.info/?p=3D1496 and a= s @selfissued. >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-497688CC-6A53-4CCB-8956-379E164F97B1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1. Good observation. 

Phil

On Dec 13, 2015, at 12:43, T= orsten Lodderstedt <torsten@lo= dderstedt.net> wrote:

=20 =20 =20 Hi Mike, Nat, John,

thanks for starting this work.

It seems you assume the AS can always be discoverd using the user id of the resource owner. I think the underlying assumption is resource servers accept access token of different (any?) user specific AS (and OP)? =46rom my perspective, RSs nowadays typically trust _the_ AS of their security domain/ecosystem and all resource owners need to have an user account with this particular AS. So I would assume the process to start at the RS. We potentially need to cover for both cases.

What do you think?

best regards,
Torsten.

Am 26.11.2015 um 00:37 schrieb Mike Jones:

I=E2=80=99m pleased to announce that Nat Saki= mura, John Bradley, and I have created an OAuth 2.0 Discovery specification.  This fills a hole in the current OAuth specification set that is necessary to achieve interoperability.  Indeed, the Interoperability section of OAuth 2.0 states:

In addition, this specification leaves a f=
ew required components partially or fully undefined (e.g., client registrati=
on, authorization server capabilities, endpoint discovery).  Without th=
ese components, clients must be manually and specifically configured against=
 a specific authorization server and resource server in order to interoperat=
e.
 
This framework was designed with the clear=
 expectation that future work will define prescriptive profiles and extensio=
ns necessary to achieve full web-scale interoperability.
        
 
        
This specification enables
            discovery of both endpoint locations and authorization
            server capabilities.

        
 
        
This specification is based=

            upon the already widely deployed
            OpenID
              Connect Discovery 1.0 specification and is compatible
            with it, by design.  The OAuth Discovery spec removes the
            portions of OpenID Connect Discovery that are OpenID
            specific and adds metadata values for Revocation and
            Introspection endpoints.  It also maps OpenID concepts, suc=
h
            as OpenID Provider, Relying Party, End-User, and Issuer to
            their OAuth underpinnings, respectively Authorization
            Server, Client, Resource Owner, and the newly introduced
            Configuration Information Location.  Some identifiers with
            names that appear to be OpenID specific were retained for
            compatibility purposes; despite the reuse of these
            identifiers that appear to be OpenID specific, their usage
            in this specification is actually referring to general OAuth
            2.0 features that are not specific to OpenID Connect.=


        
 
        
The specification is
            available at:

        
=C2=B7     &=
nbsp;  
              http://tools.ietf.org/html/draft-jon=
es-oauth-discovery-00

        
 
        
An HTML-formatted version
            is also available at:

        
=C2=B7     &=
nbsp;  
              http:=
//self-issued.info/docs/draft-jones-oauth-discovery-00.html

        
 
        
    &nb=
sp;          
                      &nbs=
p;            &n=
bsp;            =
            -- Mike

        
 
        
P.S.  This note was al=
so
            posted at 
              http://self-issued.info/?p=3D1496 and as 
              @selfissued.

      


_______________________________________________
OAuth mailing list
OAuth@i=
etf.org
https://www.ietf.org/mailman/listinfo/oauth

=20
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-497688CC-6A53-4CCB-8956-379E164F97B1-- From nobody Sun Dec 13 12:52:30 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423A71A03ED for ; Sun, 13 Dec 2015 12:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2nkVQtqSl0L for ; Sun, 13 Dec 2015 12:52:26 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A5841A037E for ; Sun, 13 Dec 2015 12:52:26 -0800 (PST) Received: by obbsd4 with SMTP id sd4so69161877obb.0 for ; Sun, 13 Dec 2015 12:52:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=8CXOGl4B7m4Kb+3Rl7BKieP6Cio259j3pa+xTA5HHHM=; b=YhX0COB6Y5AyGzLsr2NF+SSdFsi9GkeBqP22gfhvl69z/x+lW3JZ/bCZDO2B7bMBrO +uVQZIvHk+klsVQLWHFCld9XLBjpS1UlM+U2T5fo2VRudQ3CbbnRUy0ra/LaJczqFtHt ufnEk6bZkqaG603Z/xrDYYwYJAXdIu6/Dg+/RyLVTBu5kTZ8egQnifmVwmijnSPYO16P LD99CoWNiBr/PLeISXKmjReaBFx0lehD4euFWthJnrnHflr9Gs/9h3NYcDMWUFjKduc8 FCqcc15B8UnRZGrc8/HA94I8soGvVMkKaqP6Ll7LSXc7Pmj9zbLraq+65qzss1vzUBJg sUVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=8CXOGl4B7m4Kb+3Rl7BKieP6Cio259j3pa+xTA5HHHM=; b=auB3ja+yyBhi65mWQhTZvQDjuC2Y9mkow48MV/rakt3zNZ4Mjot7LDQPFykKRvXVLN 07Z5AAQyvdeKURJJCXGyVo+zJUGTw+pOX5gGfnaZ95iv3r+NSd5/x8hZ8jHuUMm9cIEo yZ+6qG1fBHltxCKDD9QFWPMybSl5MFPOMTg5Zx3sdi6LeabMXggEtHbJUzSWppjduWcJ cQS3CX0PqnkdV226RTzWwrjHY+KjFertxy78tisPJEyK50JrqMLCyrA36VFeEXaDM2w3 CbNHHrlEeaGRU7gKrWuEBSCyVfYf3MH+0Twousf+dvLn0Ez8i9+O6h3/Jm/jh4yAtLpe 1+VQ== X-Gm-Message-State: ALoCoQlpu1AHuJN+uqvPdY6s8HV/AK4SoBq21/bg+eYm541A0F/YZD8jKfB92WZL2M9b+FoVSVJlPQs8tcjL+SMFK/4vT/ssGQ== X-Received: by 10.60.60.3 with SMTP id d3mr22235938oer.24.1450039945608; Sun, 13 Dec 2015 12:52:25 -0800 (PST) Received: from [192.168.11.36] (ip-64-134-146-142.public.wayport.net. [64.134.146.142]) by smtp.gmail.com with ESMTPSA id mj8sm13548418obc.25.2015.12.13.12.52.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 13 Dec 2015 12:52:24 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_4A2C2D40-9B41-4618-871D-3F490E3C3426" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: <566DD856.1010603@lodderstedt.net> Date: Sun, 13 Dec 2015 14:52:23 -0600 Message-Id: <4294D9BE-FE7C-48DB-80D8-56744792873B@ve7jtb.com> References: <566DD856.1010603@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2015 20:52:29 -0000 --Apple-Mail=_4A2C2D40-9B41-4618-871D-3F490E3C3426 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I tend to agree that we need both. We needed to start someplace. =20 The user based discovery may better be described as finding a OAuth = Service/API for the user, authentication, photo, calendar, health record = etc. We may want to separate that from the OAuth discovery as that could be = used independently. Anyway the document is a start. John B. > On Dec 13, 2015, at 2:43 PM, Torsten Lodderstedt = wrote: >=20 > Hi Mike, Nat, John, >=20 > thanks for starting this work.=20 >=20 > It seems you assume the AS can always be discoverd using the user id = of the resource owner. I think the underlying assumption is resource = servers accept access token of different (any?) user specific AS (and = OP)? =46rom my perspective, RSs nowadays typically trust _the_ AS of = their security domain/ecosystem and all resource owners need to have an = user account with this particular AS. So I would assume the process to = start at the RS. We potentially need to cover for both cases.=20 >=20 > What do you think? >=20 > best regards, > Torsten. >=20 > Am 26.11.2015 um 00:37 schrieb Mike Jones: >> I=92m pleased to announce that Nat Sakimura, John Bradley, and I have = created an OAuth 2.0 Discovery specification. This fills a hole in the = current OAuth specification set that is necessary to achieve = interoperability. Indeed, the Interoperability section of OAuth 2.0=A0 = states: >> In addition, this specification leaves a few required components = partially or fully undefined (e.g., client registration, authorization = server capabilities, endpoint discovery). Without these components, = clients must be manually and specifically configured against a specific = authorization server and resource server in order to interoperate. >> =20 >> This framework was designed with the clear expectation that future = work will define prescriptive profiles and extensions necessary to = achieve full web-scale interoperability. >> =20 >> This specification enables discovery of both endpoint locations and = authorization server capabilities. >> =20 >> This specification is based upon the already widely deployed OpenID = Connect Discovery 1.0 = = specification and is compatible with it, by design. The OAuth Discovery = spec removes the portions of OpenID Connect Discovery that are OpenID = specific and adds metadata values for Revocation and Introspection = endpoints. It also maps OpenID concepts, such as OpenID Provider, = Relying Party, End-User, and Issuer to their OAuth underpinnings, = respectively Authorization Server, Client, Resource Owner, and the newly = introduced Configuration Information Location. Some identifiers with = names that appear to be OpenID specific were retained for compatibility = purposes; despite the reuse of these identifiers that appear to be = OpenID specific, their usage in this specification is actually referring = to general OAuth 2.0 features that are not specific to OpenID Connect. >> =20 >> The specification is available at: >> =B7 = http://tools.ie= tf.org/html/draft-jones-oauth-discovery-00 = >> =20 >> An HTML-formatted version is also available at: >> =B7 = http://self-issued.info/docs/draft-jones-oauth-discovery-00.html = >> =20 >> -- = Mike >> =20 >> P.S. This note was also posted at http://self-issued.info/?p=3D1496 = and as @selfissued = . >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 --Apple-Mail=_4A2C2D40-9B41-4618-871D-3F490E3C3426 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I tend to agree that we need both.

We needed to start someplace. =   

The= user based discovery may better be described as finding a OAuth = Service/API for the user, authentication, photo, calendar, health record = etc.
We may want to separate that from the OAuth = discovery as that could be used independently.

Anyway the document is a = start.

John = B.

On Dec 13, 2015, at 2:43 PM, Torsten = Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Mike, Nat, = John,

thanks for starting this work. 

It seems you = assume the AS can always be discoverd using the user id of the resource = owner. I think the underlying assumption is resource servers accept = access token of different (any?) user specific AS (and OP)? =46rom my = perspective, RSs nowadays typically trust _the_ AS of their security = domain/ecosystem and all resource owners need to have an user account = with this particular AS. So I would assume the process to start at the = RS. We potentially need to cover for both cases. 

What do you = think?

best regards,
Torsten.

Am 26.11.2015 um 00:37 schrieb = Mike Jones:
I=92m pleased to announce that Nat Sakimura, John Bradley, = and I have created an OAuth 2.0 Discovery specification.  This = fills a hole in the current OAuth specification set that is necessary to = achieve interoperability.  Indeed, the Interoperability section of OAuth 2.0 states:
In =
addition, this specification leaves a few required components partially =
or fully undefined (e.g., client registration, authorization server =
capabilities, endpoint discovery).  Without these components, =
clients must be manually and specifically configured against a specific =
authorization server and resource server in order to interoperate.
 
This framework was designed with the clear expectation that =
future work will define prescriptive profiles and extensions necessary =
to achieve full web-scale interoperability.
 
This specification enables = discovery of both endpoint locations and authorization server = capabilities.
 
This = specification is based upon the already widely deployed OpenID Connect Discovery 1.0 specification and is = compatible with it, by design.  The OAuth Discovery spec removes = the portions of OpenID Connect Discovery that are OpenID specific and = adds metadata values for Revocation and Introspection endpoints.  = It also maps OpenID concepts, such as OpenID Provider, Relying Party, = End-User, and Issuer to their OAuth underpinnings, respectively = Authorization Server, Client, Resource Owner, and the newly introduced = Configuration Information Location.  Some identifiers with names = that appear to be OpenID specific were retained for compatibility = purposes; despite the reuse of these identifiers that appear to be = OpenID specific, their usage in this specification is actually referring = to general OAuth 2.0 features that are not specific to OpenID = Connect.
 
The = specification is available at:
=B7         http://tools.ietf.org/html/draft-jones-oauth-discovery-00<= o:p class=3D"">
 
An = HTML-formatted version is also available at:
=B7         http://self-issued.info/docs/draft-jones-oauth-discovery-00.htm= l
 
          &nb= sp;     =             &n= bsp;           &nbs= p;            =            -- Mike
 
P.S.  This note was also = posted at http://self-issued.info/?p=3D1496 and as @selfissued.


_______________________________________________=

OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



= --Apple-Mail=_4A2C2D40-9B41-4618-871D-3F490E3C3426-- From nobody Sun Dec 13 15:33:33 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689D81A8968 for ; Sun, 13 Dec 2015 15:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3qthKrsIcBm for ; Sun, 13 Dec 2015 15:33:30 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B1421A896A for ; Sun, 13 Dec 2015 15:33:28 -0800 (PST) Received: by iofq126 with SMTP id q126so17364299iof.2 for ; Sun, 13 Dec 2015 15:33:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=E+YHJrEwdKAVFDBCemOTWuGZTIuV+uwL7VhleASE6c4=; b=AtJK7AeHrogCQ8/gOAVLUUb/yBenB5ORy/xoCtbBs1XIMhmcFvkC0Rp6aomrsDtPwE 7ZIWWD9dAoXHRb0jSjRqNdjiOCPP4bIDdIhsI+d3Qold5pJruFJ9lzBHkREQ3lfK8CcZ qY5IyUaGuZXsMG5YbPWB+qBr9sjMA80ILIN4I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=E+YHJrEwdKAVFDBCemOTWuGZTIuV+uwL7VhleASE6c4=; b=QVnvvnvvdkycOX15ppLKutuMLuJ+Hu8hi/og+vuFxzOdB2B+DvqKYeSmfqmRZZPxLK +dkmJxkPV7FDEA2iMUTvjClIlt+dcqgLYar44n0fe0RYTchV+PdM26Bcgvf4Pwp6QjqQ 9xW6gedJZuswkTnij5eZ0XpLiryOenDj1/8zfo2pGUeG10PPItMXSENcw9yAssEDyN97 58gXfglSRr0tw0bMLb9Zawlc/X2cebhC6D5jzBvhiV/X08yIorroUZoo+giUt4TJSNQw llwcrtvfkTBL5qDI6gYslyefmh7gshSIE1407lmmJc+PVFvsoCgOt0m4gNJllFp5VzId 0MmA== X-Gm-Message-State: ALoCoQn3QvM9mp0YmNynH32yHxFEC/KkTu11OI8JG4uIrX7Wa9gRJ/UqePS9GfZUYq8mt3RXNuTFhkzoKtqVv9ayAZN738ntD89Le8YFryiBF9yUKK3tIj4= X-Received: by 10.107.158.213 with SMTP id h204mr32889424ioe.129.1450049607725; Sun, 13 Dec 2015 15:33:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.23.133 with HTTP; Sun, 13 Dec 2015 15:32:58 -0800 (PST) In-Reply-To: <4294D9BE-FE7C-48DB-80D8-56744792873B@ve7jtb.com> References: <566DD856.1010603@lodderstedt.net> <4294D9BE-FE7C-48DB-80D8-56744792873B@ve7jtb.com> From: Brian Campbell Date: Sun, 13 Dec 2015 16:32:58 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a114075c2c68ee90526cffb0e Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2015 23:33:32 -0000 --001a114075c2c68ee90526cffb0e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Would it be worth considering constraining the scope of this document to the publication and content of AS metadata? And keep the actual discovery of that metadata out of scope or in a different document(s)? On Sun, Dec 13, 2015 at 1:52 PM, John Bradley wrote: > I tend to agree that we need both. > > We needed to start someplace. > > The user based discovery may better be described as finding a OAuth > Service/API for the user, authentication, photo, calendar, health record > etc. > We may want to separate that from the OAuth discovery as that could be > used independently. > > Anyway the document is a start. > > John B. > > On Dec 13, 2015, at 2:43 PM, Torsten Lodderstedt > wrote: > > Hi Mike, Nat, John, > > thanks for starting this work. > > It seems you assume the AS can always be discoverd using the user id of > the resource owner. I think the underlying assumption is resource servers > accept access token of different (any?) user specific AS (and OP)? From m= y > perspective, RSs nowadays typically trust _the_ AS of their security > domain/ecosystem and all resource owners need to have an user account wit= h > this particular AS. So I would assume the process to start at the RS. We > potentially need to cover for both cases. > > What do you think? > > best regards, > Torsten. > > Am 26.11.2015 um 00:37 schrieb Mike Jones: > > I=E2=80=99m pleased to announce that Nat Sakimura, John Bradley, and I ha= ve > created an OAuth 2.0 Discovery specification. This fills a hole in the > current OAuth specification set that is necessary to achieve > interoperability. Indeed, the Interoperability section of OAuth 2.0 > states: > > In addition, this specification leaves a few required components partiall= y or fully undefined (e.g., client registration, authorization server capab= ilities, endpoint discovery). Without these components, clients must be ma= nually and specifically configured against a specific authorization server = and resource server in order to interoperate. > > > > This framework was designed with the clear expectation that future work w= ill define prescriptive profiles and extensions necessary to achieve full w= eb-scale interoperability. > > > This specification enables discovery of both endpoint locations and > authorization server capabilities. > > This specification is based upon the already widely deployed OpenID > Connect Discovery 1.0 > specification > and is compatible with it, by design. The OAuth Discovery spec removes t= he > portions of OpenID Connect Discovery that are OpenID specific and adds > metadata values for Revocation and Introspection endpoints. It also maps > OpenID concepts, such as OpenID Provider, Relying Party, End-User, and > Issuer to their OAuth underpinnings, respectively Authorization Server, > Client, Resource Owner, and the newly introduced Configuration Informatio= n > Location. Some identifiers with names that appear to be OpenID specific > were retained for compatibility purposes; despite the reuse of these > identifiers that appear to be OpenID specific, their usage in this > specification is actually referring to general OAuth 2.0 features that ar= e > not specific to OpenID Connect. > > The specification is available at: > =C2=B7 > http://tools.ietf.org/html/draft-jones-oauth-discovery-00 > > An HTML-formatted version is also available at: > =C2=B7 http://self-issued.info/docs/draft-jones-oauth-discovery-0= 0.html > > -- Mike > > P.S. This note was also posted at http://self-issued.info/?p=3D1496 and = as > @selfissued . > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a114075c2c68ee90526cffb0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Would it be worth considering constraining the scope of th= is document to the publication and content of AS metadata? And keep the act= ual discovery of that metadata out of scope or in a different document(s)? =

On Sun,= Dec 13, 2015 at 1:52 PM, John Bradley <ve7jtb@ve7jtb.com> w= rote:
I tend to agree that we need both.

We needed to start s= omeplace. =C2=A0=C2=A0

The user based discovery ma= y better be described as finding a OAuth Service/API for the user, authenti= cation, photo, calendar, health record etc.
We may want to separa= te that from the OAuth discovery as that could be used independently.
=

Anyway the document is a start.

John B.

On Dec 13, 2015, at 2:43 PM, Torsten Lodderstedt <torsten@lodderstedt.net&= gt; wrote:

Hi Mike, Nat, John,

thanks for starting this work.=C2=A0

It seems you assume the AS can always be discoverd= using the user id of the resource owner. I think the underlying assumption= is resource servers accept access token of different (any?) user specific = AS (and OP)? From my perspective, RSs nowadays typically trust _the_ AS of = their security domain/ecosystem and all resource owners need to have an use= r account with this particular AS. So I would assume the process to start a= t the RS. We potentially need to cover for both cases.=C2=A0

What do you think?

best regards,
Torsten.
Am 26.11.2015 um 00:37 schrieb Mike Jones:
<= blockquote type=3D"cite" style=3D"font-family:Helvetica;font-size:12px;font= -style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;= line-height:normal;text-align:start;text-indent:0px;text-transform:none;whi= te-space:normal;word-spacing:0px;background-color:rgb(255,255,255)">
I=E2=80=99m pleased to announce that Nat Sakimura, John Bradley, an= d I have created an OAuth 2.0 Discovery specification.=C2=A0 This fills a h= ole in the current OAuth specification set that is necessary to achieve int= eroperability.=C2=A0 Indeed, the=C2=A0Interoperability section of OAuth 2.0<= span>=C2=A0states:
In addition, this specification leaves =
a few required components partially or fully undefined (e.g., client regist=
ration, authorization server capabilities, endpoint discovery).=C2=A0 Witho=
ut these components, clients must be manually and specifically configured a=
gainst a specific authorization server and resource server in order to inte=
roperate.
=C2=A0
This framework was designed with the clear exp=
ectation that future work will define prescriptive profiles and extensions =
necessary to achieve full web-scale interoperability.<=
/pre>
=C2=A0
This specification enables discovery of both endpoint locations and au=
thorization server capabilities.
=C2=A0
This specificati=
on is based upon the already widely deployed=C2=A0OpenID Connect D=
iscovery 1.0=C2=A0specification and is compatible with it,=
 by design.=C2=A0 The OAuth Discovery spec removes the portions of OpenID C=
onnect Discovery that are OpenID specific and adds metadata values for Revo=
cation and Introspection endpoints.=C2=A0 It also maps OpenID concepts, suc=
h as OpenID Provider, Relying Party, End-User, and Issuer to their OAuth un=
derpinnings, respectively Authorization Server, Client, Resource Owner, and=
 the newly introduced Configuration Information Location.=C2=A0 Some identi=
fiers with names that appear to be OpenID specific were retained for compat=
ibility purposes; despite the reuse of these identifiers that appear to be =
OpenID specific, their usage in this specification is actually referring to=
 general OAuth 2.0 features that are not specific to OpenID Connect.=

=C2=A0
The specification is available at:=

=
=C2=B7=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<=
/span>http://tools.ietf.org/html/draft-jones-oauth-dis=
covery-00
=C2=A0<=
/span>
An HTML-formatted version is also a=
vailable at:
=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0http://self-issued.info/docs/draft-jones-oauth-discovery-00.html
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-- Mi=
ke
=C2=A0
P.S.=C2=A0 This note was also posted at=
=C2=A0http://self-iss=
ued.info/?p=3D1496=C2=A0and as=C2=A0@selfissued.<=
/div>


______________________=
_________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/oauth




_______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--001a114075c2c68ee90526cffb0e-- From nobody Sun Dec 13 19:13:40 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F1D1A007A for ; Sun, 13 Dec 2015 19:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BM1DDf6NE7vg for ; Sun, 13 Dec 2015 19:13:37 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30D131A7003 for ; Sun, 13 Dec 2015 19:13:37 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id n186so26840718wmn.0 for ; Sun, 13 Dec 2015 19:13:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=1ijwiYcTXJzr+n5fV7J72X3JCMxOhEkmx7DPG4pieYE=; b=d2O8x4WUzlekQDzNiQlV+VgAoGZZbV6dayoZs9zKfAHFJm1/zEROYZ4GG1OocsmArt KlUgq0+PHJKdsFY4cQFbKqXcxXwyY8DucjetiZ5JFtoK3sf+D/1SjTg5RhSFDY625nY6 D1jhVcslCqCnD2f5Xvf32++mBlCHCD7GovSuNzF1Xl7UnO7dhcAouA56t2J3ZIFzCzn/ hoXjs1VtnUeCes21EQpZNdBXWsk7NjRmPQujH29rY8gh3RyN9InWXoCfZEfppyR2ddXI pq73VvwVUIeLaSiu2CZEPSJyDwA/oeBPtIsFWBvqDNcmN5VGzCW6U/P9R+5HlwsXNUgV GkBA== MIME-Version: 1.0 X-Received: by 10.28.126.215 with SMTP id z206mr21547024wmc.71.1450062815858; Sun, 13 Dec 2015 19:13:35 -0800 (PST) Received: by 10.28.52.130 with HTTP; Sun, 13 Dec 2015 19:13:35 -0800 (PST) Date: Sun, 13 Dec 2015 22:13:35 -0500 Message-ID: From: Kathleen Moriarty To: "oauth@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 03:13:39 -0000 Hi, Are there any implementations of draft-ietf-oauth-proof-of-possession? Thanks! -- Best regards, Kathleen From nobody Sun Dec 13 19:40:47 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65A81A2119 for ; Sun, 13 Dec 2015 19:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZ9BpNf6jyae for ; Sun, 13 Dec 2015 19:40:38 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0744.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::744]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41CC51A1F1D for ; Sun, 13 Dec 2015 19:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=j3idq7mGCD3JPDmR6+U9dYiT5d2rO0MFLe3HMsefe0I=; b=GY60MgKWOINUL5lGS+WnZlnvifdBcMqhxnt6qRuf0N4gw278kXFCakFAq7PpSJUUo0kODTppZyQ8Wu4RQ83761+Jq2T6fi2LGoVCx5qQfc6UZgKJ8uqWnlB2wG7Jo8I/sMYgWR8ig1jBe2ywLD4U27ta8r+VJRVXB2PSg6Eo+Y8= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.355.16; Mon, 14 Dec 2015 03:40:17 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0355.012; Mon, 14 Dec 2015 03:40:17 +0000 From: Mike Jones To: Kathleen Moriarty , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-possession Thread-Index: AQHRNh1yckJg5FSS3k+scclzNoZqUp7J0+DA Date: Mon, 14 Dec 2015 03:40:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [188.92.133.18] x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:6gJtZB6/W/3uhWitRKLEE5xjoczHu9zTvXip/x6YrR0v3VWqF0MNJPlC6SphM0HB0rZhPLxiUFQaS5VuMR2vUAevmjkh/DMSrRVdP8aWAScHFFt7dk30GLEa7bgl+fdrSN/LKEQqyxV0SLmgZl+0+A==; 24:Ro2HVEUfds+hxtrJ+QTADNBcwrtes9JcFu3DMP7bOy+wQX4V2DvrbMkWy6mpU/iqA0uO9slgtTTrC52QeezBIU9nNs7EL6b1uZh1hJTx3kw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 0790FB1F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(189002)(13464003)(199003)(5004730100002)(76576001)(10290500002)(10400500002)(106116001)(105586002)(86362001)(5005710100001)(106356001)(10090500001)(97736004)(122556002)(5002640100001)(5001770100001)(189998001)(33656002)(8990500004)(5001960100002)(107886002)(81156007)(19580395003)(92566002)(19580405001)(86612001)(99286002)(11100500001)(74316001)(16601075003)(2501003)(15975445007)(6116002)(586003)(102836003)(3846002)(77096005)(54356999)(66066001)(1096002)(1220700001)(2900100001)(2950100001)(101416001)(5008740100001)(87936001)(230783001)(76176999)(50986999)(5003600100002)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2015 03:40:17.4098 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Subject: Re: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 03:40:45 -0000 Yes. Xbox One and its partners have been using this since its launch. The= following token claims are from a production trace captured in early 2013: { "iss":"xas.xboxlive.com", "aud":"http://auth.xboxlive.com", "exp":"1361398824", "nbf":"1360189224", "cnf":{ "jwk":{ "kty":"EC", "use":"sig", "crv":"P-256", "x":"18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM", "y":"-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA" } } } -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen Moriarty Sent: Sunday, December 13, 2015 7:14 PM To: oauth@ietf.org Subject: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-possession Hi, Are there any implementations of draft-ietf-oauth-proof-of-possession? Thanks! --=20 Best regards, Kathleen _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Sun Dec 13 19:59:18 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC2D1A8830 for ; Sun, 13 Dec 2015 19:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcZroDVByKUg for ; Sun, 13 Dec 2015 19:59:15 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F5E1A87AA for ; Sun, 13 Dec 2015 19:59:14 -0800 (PST) Received: by wmnn186 with SMTP id n186so103557621wmn.0 for ; Sun, 13 Dec 2015 19:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+JZOmQd+5fMwlE/xDpGqYxu8AbMsrD00bTBufdGwekM=; b=lG2VwwiJSVSv05Ks18S2X7VJtSksMqhJrjN0YbbaGOeStgGZn3SnYlqlrZI4XSuDB/ qaisiieEQUn6cS5IabGuDPcUtybrNqsWhyhICjTlp9A5i4Og0x6pdH5g1uTyXBe0oApY P6wkJBgWzNmz17kydCBbVrURVMga+5OGTrZpAs4CYAr7mYdOJhgaoR++p2h4tb0TnpQo dngKrweRaRrXnHphSZo7/895Q/1odnqbmp0poXCyMRIfcJpe8SKVwGLp04QahtGPo/vN Ct6bOPcHcLmzylA1Ipltb6gxkXRVc3hUn58EFAOMOjxzQd4MAryW6GTaqr4nKw0NtciI wRSw== MIME-Version: 1.0 X-Received: by 10.28.224.7 with SMTP id x7mr20497131wmg.17.1450065553630; Sun, 13 Dec 2015 19:59:13 -0800 (PST) Received: by 10.28.52.130 with HTTP; Sun, 13 Dec 2015 19:59:13 -0800 (PST) In-Reply-To: References: Date: Sun, 13 Dec 2015 22:59:13 -0500 Message-ID: From: Kathleen Moriarty To: Mike Jones Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 03:59:18 -0000 Thanks, Mike! On Sun, Dec 13, 2015 at 10:40 PM, Mike Jones wrote: > Yes. Xbox One and its partners have been using this since its launch. The following token claims are from a production trace captured in early 2013: > > { > "iss":"xas.xboxlive.com", > "aud":"http://auth.xboxlive.com", > "exp":"1361398824", > "nbf":"1360189224", > "cnf":{ > "jwk":{ > "kty":"EC", > "use":"sig", > "crv":"P-256", > "x":"18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM", > "y":"-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA" > } > } > } > > -- Mike > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen Moriarty > Sent: Sunday, December 13, 2015 7:14 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-possession > > Hi, > > Are there any implementations of draft-ietf-oauth-proof-of-possession? > > Thanks! > > -- > > Best regards, > Kathleen > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Best regards, Kathleen From nobody Sun Dec 13 20:03:52 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004CE1A88E4 for ; Sun, 13 Dec 2015 20:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_NZMm6TFRpY for ; Sun, 13 Dec 2015 20:03:48 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id E02411A8890 for ; Sun, 13 Dec 2015 20:03:47 -0800 (PST) X-IronPort-AV: E=Sophos; i="5.20,425,1444654800"; d="scan'208,217"; a="46853766" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 14 Dec 2015 15:03:45 +1100 X-IronPort-AV: E=McAfee;i="5700,7163,8014"; a="69948046" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcbvi.tcif.telstra.com.au with ESMTP; 14 Dec 2015 15:03:45 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Mon, 14 Dec 2015 15:03:45 +1100 From: "Manger, James" To: Mike Jones , Kathleen Moriarty , "oauth@ietf.org" Date: Mon, 14 Dec 2015 15:03:44 +1100 Thread-Topic: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-possession Thread-Index: AQHRNh1yckJg5FSS3k+scclzNoZqUp7J0+DAgAAFEQA= Message-ID: <255B9BB34FB7D647A506DC292726F6E13BB4EA5AD2@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E13BB4EA5AD2WSMSG3153Vsrv_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 04:03:51 -0000 --_000_255B9BB34FB7D647A506DC292726F6E13BB4EA5AD2WSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That value uses strings for expiry and not-before dates so it is not a vali= d JWT; these dates need to be numbers. 3 of the examples in draft-ietf-oauth-proof-of-possession are similarly inv= alid ("exp" and "iat"); 1 example gets it right. -- James Manger -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones Sent: Monday, 14 December 2015 2:40 PM To: Kathleen Moriarty ; oauth@ietf.org Subject: Re: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-posses= sion Yes. Xbox One and its partners have been using this since its launch. The= following token claims are from a production trace captured in early 2013: { "iss":"xas.xboxlive.com", "aud":"http://auth.xboxlive.com", "exp":"1361398824", "nbf":"1360189224", "cnf":{ "jwk":{ "kty":"EC", "use":"sig", "crv":"P-256", "x":"18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM", "y":"-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA" } } } -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen Moriarty Sent: Sunday, December 13, 2015 7:14 PM To: oauth@ietf.org Subject: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-possession Hi, Are there any implementations of draft-ietf-oauth-proof-of-possession? Thanks! -- Best regards, Kathleen _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_255B9BB34FB7D647A506DC292726F6E13BB4EA5AD2WSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That = value uses strings for expiry and not-before dates so it is not a valid JWT= ; these dates need to be numbers.

 

3 of the examples in draft-ietf-o= auth-proof-of-possession are similarly invalid (“exp” and ̶= 0;iat”); 1 example gets it right.

 

--

James Manger

&nb= sp;

-----Original Message-----
From: OAuth [mailto:oauth-b= ounces@ietf.org] On Behalf Of Mike Jones
Sent: Monday, 14 December 2015 = 2:40 PM
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>; = oauth@ietf.org
Subject: Re: [OAUTH-WG] implementations of draft-ietf-oau= th-proof-of-possession

 <= /p>

Yes.  Xbox One and its partners have been u= sing this since its launch.  The following token claims are from a pro= duction trace captured in early 2013:

 

  {

   "iss":"xas.xboxlive.c= om",

   "aud":"http://= auth.xboxlive.com",

   "exp":&qu= ot;1361398824",

   "nbf":"1360189224&q= uot;,

   "cnf":{

   &nbs= p; "jwk":{

       "kty&= quot;:"EC",

       "use= ":"sig",

       "c= rv":"P-256",

       &qu= ot;x":"18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM",

=        "y":"-V4dS4UaLMgP_4fY4j= 8ir7cl1TXlFdAgcx55o7TkcSA"

      }

    }

  }

 

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;          -- Mike

 

-----Original Message-----

From: OAu= th [mailto:oauth-bounces@ietf.org] On Behal= f Of Kathleen Moriarty

Sent: Sunday, = December 13, 2015 7:14 PM

To: oauth@ietf.org

Subje= ct: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-possession=

 

Hi,

 

Are there any implementations of  draft-ietf-oauth-pro= of-of-possession?

 

Thanks!

 

--

 

Best regards,

Kathleen

 

___________________________= ____________________

OAuth mailing li= st

= OAuth@ietf.org=

https://www.ietf.org/mailman/listinfo/oauth

 

_________= ______________________________________

OAuth mailing list

OAu= th@ietf.org

https://www.ietf.org/mailman/listinfo/oauth=

= --_000_255B9BB34FB7D647A506DC292726F6E13BB4EA5AD2WSMSG3153Vsrv_-- From nobody Sun Dec 13 20:08:06 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95CD91A8942 for ; Sun, 13 Dec 2015 20:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdRZ3w7563ZC for ; Sun, 13 Dec 2015 20:08:01 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0104.outbound.protection.outlook.com [207.46.100.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A6F71A8848 for ; Sun, 13 Dec 2015 20:08:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3xK8cOoHuUJq878pjAaMuI4tm6D+4t59L/nN+mFihgI=; b=PWv3aBRzCLj4EPmRL4vgothvKDJCRYlC3IsmcuxcJRgsv9sPTOLBUECYT/z0O4luxkGF7mt4FpILMYkvWBnW7W7GVQ0M4yT4ZaNY5yx8IYv327oNQUs30YwIKsY273r7ngctU9/KuI0gL1YjYltjRjbDWrPrn8dbwA/bWRlb/6U= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.355.16; Mon, 14 Dec 2015 04:07:58 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0355.012; Mon, 14 Dec 2015 04:07:58 +0000 From: Mike Jones To: "Manger, James" , Kathleen Moriarty , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-possession Thread-Index: AQHRNiRw/3FJeypoUkyGZPCG7cxomZ7J3VGA Date: Mon, 14 Dec 2015 04:07:58 +0000 Message-ID: References: <255B9BB34FB7D647A506DC292726F6E13BB4EA5AD2@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BB4EA5AD2@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [188.92.133.18] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:Nf6ZybIVqj+5CS0wIN2Rh7IWD4U6TUm4T8vCZzbVLK1rGyYbtqO4ZkzjabIx7AGkChzOXPAi8YE98PAu+aJ5SeIHWhIA5oguWf79LnBgh1euRXRqpkaI/ulQDrLO2aY/vErXU/8OjCOhnyfovsJaFg==; 24:W/ryAxzgFKdbk+zGkje/32Ff6xDNOhKanL3ZXU4BsnYJ5mAK/0+O0VPPL8ST48mjGawpCLWlXJ5ekqcFXVA31Ut3TQ5tq3yEhoJGbw8YJUE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0790FB1F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(13464003)(199003)(52604005)(377454003)(43784003)(189002)(189998001)(50986999)(97736004)(54356999)(15975445007)(2900100001)(76576001)(81156007)(87936001)(2501003)(1220700001)(6116002)(3846002)(586003)(102836003)(122556002)(1096002)(77096005)(790700001)(92566002)(16601075003)(40100003)(86612001)(5001770100001)(33656002)(5001960100002)(5002640100001)(11100500001)(99286002)(19580395003)(5008740100001)(66066001)(74316001)(106356001)(2950100001)(106116001)(105586002)(76176999)(107886002)(10290500002)(16236675004)(86362001)(10090500001)(19580405001)(19300405004)(5003600100002)(19625215002)(5005710100001)(8990500004)(19617315012)(10400500002)(101416001)(230783001)(5004730100002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB44269B105305F4246D0563DF5ED0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2015 04:07:58.5840 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Subject: Re: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 04:08:04 -0000 --_000_BY2PR03MB44269B105305F4246D0563DF5ED0BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good eye, James! Thanks for catching this. I'll fix it right away. It turns out that examples are based on the trace captured in February 2013= - well before the Xbox One launch in November 2013. I'd actually noticed = this then and had Xbox correct their code. But silly me, I failed to unifo= rmly correct it in the draft. Thanks again! -- Mike From: Manger, James [mailto:James.H.Manger@team.telstra.com] Sent: Sunday, December 13, 2015 8:04 PM To: Mike Jones ; Kathleen Moriarty ; oauth@ietf.org Subject: RE: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-posses= sion That value uses strings for expiry and not-before dates so it is not a vali= d JWT; these dates need to be numbers. 3 of the examples in draft-ietf-oauth-proof-of-possession are similarly inv= alid ("exp" and "iat"); 1 example gets it right. -- James Manger -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones Sent: Monday, 14 December 2015 2:40 PM To: Kathleen Moriarty >; oauth@ietf.org Subject: Re: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-posses= sion Yes. Xbox One and its partners have been using this since its launch. The= following token claims are from a production trace captured in early 2013: { "iss":"xas.xboxlive.com", "aud":"http://auth.xboxlive.com", "exp":"1361398824", "nbf":"1360189224", "cnf":{ "jwk":{ "kty":"EC", "use":"sig", "crv":"P-256", "x":"18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM", "y":"-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA" } } } -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen Moriarty Sent: Sunday, December 13, 2015 7:14 PM To: oauth@ietf.org Subject: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-possession Hi, Are there any implementations of draft-ietf-oauth-proof-of-possession? Thanks! -- Best regards, Kathleen _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_BY2PR03MB44269B105305F4246D0563DF5ED0BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good eye, James! = Thanks for catching this.  I’ll fix it right away.

 

It turns out that exam= ples are based on the trace captured in February 2013 – well before t= he Xbox One launch in November 2013.  I’d actually noticed this = then and had Xbox correct their code.  But silly me, I failed to uniformly correct it in the draft.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    Thanks again!

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    -- Mike

 

From: Manger, James [mailto:James.H.Manger@te= am.telstra.com]
Sent: Sunday, December 13, 2015 8:04 PM
To: Mike Jones <Michael.Jones@microsoft.com>; Kathleen Moriart= y <kathleen.moriarty.ietf@gmail.com>; oauth@ietf.org
Subject: RE: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of= -possession

 

That value uses strings for = expiry and not-before dates so it is not a valid JWT; these dates need to b= e numbers.

 

3 of the examples in draft-i= etf-oauth-proof-of-possession are similarly invalid (“exp” and = “iat”); 1 example gets it right.

 

--

James Manger

 

-----O= riginal Message-----
From: OAuth [mailto:oauth-bounces= @ietf.org] On Behalf Of Mike Jones
Sent: Monday, 14 December 2015 2:40 PM
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-posses= sion

 

Yes.  Xbox One and its = partners have been using this since its launch.  The following token c= laims are from a production trace captured in early 2013:=

 

  {

   "iss":"xas.xboxlive.com",

   "aud":"= http://auth.xboxlive.= com",

   "exp":"1361398824",

   "nbf":"1360189224",

   "cnf":{

     "jwk":{

       "kty":"EC",

       "use":"sig",

       "crv":"P-256",<= o:p>

       "x":"18wHLeIgW9wVN6V= D1Txgpqy2LszYkMf6J8njVAibvhM",

       "y":"-V4dS4UaLMgP_4f= Y4j8ir7cl1TXlFdAgcx55o7TkcSA"

      }

    }

  }

 

    &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;         -- Mike

 

-----Original Message-----

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen Moria= rty

Sent: Sunday, December 13, 2= 015 7:14 PM

To: oauth@ietf.= org

Subject: [OAUTH-WG] implemen= tations of draft-ietf-oauth-proof-of-possession

 

Hi,

 

Are there any implementation= s of  draft-ietf-oauth-proof-of-possession?

 

Thanks!

 

--

 

Best regards,

Kathleen

 

____________________________= ___________________

OAuth mailing list

OAuth@ietf.org<= /span>

https://www.ietf.org/mailman/listinfo/oauth

 

____________________________= ___________________

OAuth mailing list

OAuth@ietf.org<= /span>

https://www.ietf.org/mailman/listinfo/oauth

--_000_BY2PR03MB44269B105305F4246D0563DF5ED0BY2PR03MB442namprd_-- From nobody Sun Dec 13 20:09:24 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BD21A8942 for ; Sun, 13 Dec 2015 20:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kme6Sw1OrufG for ; Sun, 13 Dec 2015 20:09:20 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C59D1A8848 for ; Sun, 13 Dec 2015 20:09:20 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id n186so27763408wmn.0 for ; Sun, 13 Dec 2015 20:09:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qK6hWEBe8VtORB1L20dqPpc24GEUO9af07hBkozAiFA=; b=hMgBz37s+MZqcKwABCk0HMaz3U0yUTqMiCrvzQ1cGa/IRlaEugPYpMOzH+/aADRoOM /Gh3sczeugbbahnr0WDKLcjd5Ektnj8PsRzKT3aIFiZxD6TT6DHnyTpHikD0Yt2BDqs8 sA1JLegf24b3wyDPzCvcbbwZARkaX9QBXRnFunTv9czwJJfxZFIbBpSVxPrE/CcNjOR0 7rqdkSAwwQ4CPQzxXN3DF7S6epjFlI4fXrE17ujLmHEFru0uEMbN6ln/v+1jKuyVSEUQ qx/Smrh6PVgi+LOOmxMcf1vZI4C0C3zREBgyDgiA1ClME88lySDDSePmEtB+DAdZYxaH 0ooQ== MIME-Version: 1.0 X-Received: by 10.28.224.7 with SMTP id x7mr20530811wmg.17.1450066159022; Sun, 13 Dec 2015 20:09:19 -0800 (PST) Received: by 10.28.52.130 with HTTP; Sun, 13 Dec 2015 20:09:18 -0800 (PST) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E13BB4EA5AD2@WSMSG3153V.srv.dir.telstra.com> Date: Sun, 13 Dec 2015 23:09:18 -0500 Message-ID: From: Kathleen Moriarty To: Mike Jones Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 04:09:22 -0000 I just added the ballot for these drafts, can this be fixed quickly? Thanks. Kathleen On Sun, Dec 13, 2015 at 11:07 PM, Mike Jones wrote: > Good eye, James! Thanks for catching this. I=E2=80=99ll fix it right aw= ay. > > > > It turns out that examples are based on the trace captured in February 20= 13 > =E2=80=93 well before the Xbox One launch in November 2013. I=E2=80=99d = actually noticed > this then and had Xbox correct their code. But silly me, I failed to > uniformly correct it in the draft. > > > > Thanks again! > > -- Mike > > > > From: Manger, James [mailto:James.H.Manger@team.telstra.com] > Sent: Sunday, December 13, 2015 8:04 PM > To: Mike Jones ; Kathleen Moriarty > ; oauth@ietf.org > Subject: RE: [OAUTH-WG] implementations of > draft-ietf-oauth-proof-of-possession > > > > That value uses strings for expiry and not-before dates so it is not a va= lid > JWT; these dates need to be numbers. > > > > 3 of the examples in draft-ietf-oauth-proof-of-possession are similarly > invalid (=E2=80=9Cexp=E2=80=9D and =E2=80=9Ciat=E2=80=9D); 1 example gets= it right. > > > > -- > > James Manger > > > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones > Sent: Monday, 14 December 2015 2:40 PM > To: Kathleen Moriarty ; oauth@ietf.org > Subject: Re: [OAUTH-WG] implementations of > draft-ietf-oauth-proof-of-possession > > > > Yes. Xbox One and its partners have been using this since its launch. T= he > following token claims are from a production trace captured in early 2013= : > > > > { > > "iss":"xas.xboxlive.com", > > "aud":"http://auth.xboxlive.com", > > "exp":"1361398824", > > "nbf":"1360189224", > > "cnf":{ > > "jwk":{ > > "kty":"EC", > > "use":"sig", > > "crv":"P-256", > > "x":"18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM", > > "y":"-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA" > > } > > } > > } > > > > -- Mike > > > > -----Original Message----- > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen Moriart= y > > Sent: Sunday, December 13, 2015 7:14 PM > > To: oauth@ietf.org > > Subject: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-possessi= on > > > > Hi, > > > > Are there any implementations of draft-ietf-oauth-proof-of-possession? > > > > Thanks! > > > > -- > > > > Best regards, > > Kathleen > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth --=20 Best regards, Kathleen From nobody Sun Dec 13 20:11:12 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9C61A8897 for ; Sun, 13 Dec 2015 20:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n_kM31mXIM5w for ; Sun, 13 Dec 2015 20:11:08 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0756.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:756]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C8F01A87E1 for ; Sun, 13 Dec 2015 20:11:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3juq6QRTNB7RZ8CzrAcQkfjmEEWQqhjCrs4WJG5aflM=; b=Xer7KRznJQHWom1kQiHos0/yFoVPQNLvjKL4JH3JWOR7+jtL8vH2faNLE1nGISVQz2DMSOmbTXKXv5yYLDeVVZtQ91k5h02Xx9LhtnG6A96r7UGbgj8hMLKvAytGCgpGtoiQDjjEY2JNU8cHeHm8dn4byK1Vdmtxebf/2D6wx+4= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.355.16; Mon, 14 Dec 2015 04:10:43 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0355.012; Mon, 14 Dec 2015 04:10:43 +0000 From: Mike Jones To: Kathleen Moriarty Thread-Topic: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-possession Thread-Index: AQHRNiU1IGc6XVuMlEWvFje82tqI857J3k5Q Date: Mon, 14 Dec 2015 04:10:43 +0000 Message-ID: References: <255B9BB34FB7D647A506DC292726F6E13BB4EA5AD2@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [188.92.133.18] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:6e/1pu6qEoHVn8AuRf+QcHc6HkI+c1RHIo1Ow/1+woUqNNzdE2Ft4eaPHqkjazADcO72EqLesrgJiQd4AakpumbU3VBQ3K0PVKOGyFB7KMVI3tb1lr8bxXYIh/OpQ2jc0/AsEDlwP2/w+n3dvk8Ytw==; 24:Z7RIN0xlLViOnRel6DEEsIDNG6aqGf9/F2HY9829hfD/cQwr/qnzJQgDLOm0Oa+095eq9SyNzsMnjZN0F5KXRMvsYIbxbWOUn9UWZTzGdis= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0790FB1F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(199003)(52604005)(377454003)(43784003)(189002)(189998001)(50986999)(97736004)(54356999)(15975445007)(2900100001)(76576001)(81156007)(87936001)(1220700001)(6116002)(3846002)(586003)(102836003)(122556002)(1096002)(77096005)(92566002)(16601075003)(40100003)(86612001)(33656002)(5001960100002)(5002640100001)(11100500001)(99286002)(19580395003)(5008740100001)(66066001)(74316001)(106356001)(2950100001)(106116001)(105586002)(76176999)(10290500002)(86362001)(93886004)(10090500001)(19580405001)(5003600100002)(5005710100001)(8990500004)(10400500002)(101416001)(230783001)(5004730100002)(110136002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2015 04:10:43.3866 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 04:11:11 -0000 UmlnaHQgYXdheS4gIFRoZSBvbmx5IGNoYW5nZSB3aWxsIGJlIHRvIHJlbW92ZSBzb21lIGRvdWJs ZS1xdW90ZXMgYXJvdW5kIG51bWJlcnMuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBLYXRobGVlbiBNb3JpYXJ0eSBbbWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21h aWwuY29tXSANClNlbnQ6IFN1bmRheSwgRGVjZW1iZXIgMTMsIDIwMTUgODowOSBQTQ0KVG86IE1p a2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4NCkNjOiBNYW5nZXIsIEphbWVz IDxKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPjsgb2F1dGhAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbT0FVVEgtV0ddIGltcGxlbWVudGF0aW9ucyBvZiBkcmFmdC1pZXRmLW9hdXRoLXBy b29mLW9mLXBvc3Nlc3Npb24NCg0KSSBqdXN0IGFkZGVkIHRoZSBiYWxsb3QgZm9yIHRoZXNlIGRy YWZ0cywgY2FuIHRoaXMgYmUgZml4ZWQgcXVpY2tseT8NCg0KVGhhbmtzLg0KS2F0aGxlZW4NCg0K T24gU3VuLCBEZWMgMTMsIDIwMTUgYXQgMTE6MDcgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+IEdvb2QgZXllLCBKYW1lcyEgIFRoYW5rcyBmb3Ig Y2F0Y2hpbmcgdGhpcy4gIEnigJlsbCBmaXggaXQgcmlnaHQgYXdheS4NCj4NCj4NCj4NCj4gSXQg dHVybnMgb3V0IHRoYXQgZXhhbXBsZXMgYXJlIGJhc2VkIG9uIHRoZSB0cmFjZSBjYXB0dXJlZCBp biBGZWJydWFyeSANCj4gMjAxMyDigJMgd2VsbCBiZWZvcmUgdGhlIFhib3ggT25lIGxhdW5jaCBp biBOb3ZlbWJlciAyMDEzLiAgSeKAmWQgYWN0dWFsbHkgDQo+IG5vdGljZWQgdGhpcyB0aGVuIGFu ZCBoYWQgWGJveCBjb3JyZWN0IHRoZWlyIGNvZGUuICBCdXQgc2lsbHkgbWUsIEkgDQo+IGZhaWxl ZCB0byB1bmlmb3JtbHkgY29ycmVjdCBpdCBpbiB0aGUgZHJhZnQuDQo+DQo+DQo+DQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGFu a3MgYWdhaW4hDQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLSBNaWtlDQo+DQo+DQo+DQo+IEZyb206IE1hbmdlciwgSmFtZXMg W21haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tXQ0KPiBTZW50OiBTdW5kYXks IERlY2VtYmVyIDEzLCAyMDE1IDg6MDQgUE0NCj4gVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbT47IEthdGhsZWVuIE1vcmlhcnR5IA0KPiA8a2F0aGxlZW4ubW9yaWFy dHkuaWV0ZkBnbWFpbC5jb20+OyBvYXV0aEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW09BVVRI LVdHXSBpbXBsZW1lbnRhdGlvbnMgb2YgDQo+IGRyYWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9z c2Vzc2lvbg0KPg0KPg0KPg0KPiBUaGF0IHZhbHVlIHVzZXMgc3RyaW5ncyBmb3IgZXhwaXJ5IGFu ZCBub3QtYmVmb3JlIGRhdGVzIHNvIGl0IGlzIG5vdCBhIA0KPiB2YWxpZCBKV1Q7IHRoZXNlIGRh dGVzIG5lZWQgdG8gYmUgbnVtYmVycy4NCj4NCj4NCj4NCj4gMyBvZiB0aGUgZXhhbXBsZXMgaW4g ZHJhZnQtaWV0Zi1vYXV0aC1wcm9vZi1vZi1wb3NzZXNzaW9uIGFyZSANCj4gc2ltaWxhcmx5IGlu dmFsaWQgKOKAnGV4cOKAnSBhbmQg4oCcaWF04oCdKTsgMSBleGFtcGxlIGdldHMgaXQgcmlnaHQu DQo+DQo+DQo+DQo+IC0tDQo+DQo+IEphbWVzIE1hbmdlcg0KPg0KPg0KPg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWtlIEpvbmVzDQo+IFNlbnQ6IE1vbmRheSwgMTQgRGVjZW1i ZXIgMjAxNSAyOjQwIFBNDQo+IFRvOiBLYXRobGVlbiBNb3JpYXJ0eSA8a2F0aGxlZW4ubW9yaWFy dHkuaWV0ZkBnbWFpbC5jb20+OyANCj4gb2F1dGhAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtP QVVUSC1XR10gaW1wbGVtZW50YXRpb25zIG9mIA0KPiBkcmFmdC1pZXRmLW9hdXRoLXByb29mLW9m LXBvc3Nlc3Npb24NCj4NCj4NCj4NCj4gWWVzLiAgWGJveCBPbmUgYW5kIGl0cyBwYXJ0bmVycyBo YXZlIGJlZW4gdXNpbmcgdGhpcyBzaW5jZSBpdHMgbGF1bmNoLiAgDQo+IFRoZSBmb2xsb3dpbmcg dG9rZW4gY2xhaW1zIGFyZSBmcm9tIGEgcHJvZHVjdGlvbiB0cmFjZSBjYXB0dXJlZCBpbiBlYXJs eSAyMDEzOg0KPg0KPg0KPg0KPiAgIHsNCj4NCj4gICAgImlzcyI6Inhhcy54Ym94bGl2ZS5jb20i LA0KPg0KPiAgICAiYXVkIjoiaHR0cDovL2F1dGgueGJveGxpdmUuY29tIiwNCj4NCj4gICAgImV4 cCI6IjEzNjEzOTg4MjQiLA0KPg0KPiAgICAibmJmIjoiMTM2MDE4OTIyNCIsDQo+DQo+ICAgICJj bmYiOnsNCj4NCj4gICAgICAiandrIjp7DQo+DQo+ICAgICAgICAia3R5IjoiRUMiLA0KPg0KPiAg ICAgICAgInVzZSI6InNpZyIsDQo+DQo+ICAgICAgICAiY3J2IjoiUC0yNTYiLA0KPg0KPiAgICAg ICAgIngiOiIxOHdITGVJZ1c5d1ZONlZEMVR4Z3BxeTJMc3pZa01mNko4bmpWQWlidmhNIiwNCj4N Cj4gICAgICAgICJ5IjoiLVY0ZFM0VWFMTWdQXzRmWTRqOGlyN2NsMVRYbEZkQWdjeDU1bzdUa2NT QSINCj4NCj4gICAgICAgfQ0KPg0KPiAgICAgfQ0KPg0KPiAgIH0NCj4NCj4NCj4NCj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC0tIA0KPiBNaWtlDQo+DQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+DQo+ IEZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEthdGhsZWVuIA0KPiBNb3JpYXJ0eQ0KPg0KPiBTZW50OiBTdW5kYXksIERlY2VtYmVyIDEzLCAy MDE1IDc6MTQgUE0NCj4NCj4gVG86IG9hdXRoQGlldGYub3JnDQo+DQo+IFN1YmplY3Q6IFtPQVVU SC1XR10gaW1wbGVtZW50YXRpb25zIG9mIA0KPiBkcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBv c3Nlc3Npb24NCj4NCj4NCj4NCj4gSGksDQo+DQo+DQo+DQo+IEFyZSB0aGVyZSBhbnkgaW1wbGVt ZW50YXRpb25zIG9mICBkcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Npb24/DQo+DQo+ DQo+DQo+IFRoYW5rcyENCj4NCj4NCj4NCj4gLS0NCj4NCj4NCj4NCj4gQmVzdCByZWdhcmRzLA0K Pg0KPiBLYXRobGVlbg0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPg0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4NCj4gT0F1dGhAaWV0 Zi5vcmcNCj4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K Pg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPg0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4NCj4gT0F1dGhAaWV0Zi5vcmcNCj4NCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KLS0gDQoNCkJl c3QgcmVnYXJkcywNCkthdGhsZWVuDQo= From nobody Sun Dec 13 20:32:01 2015 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD1F1A9118; Sun, 13 Dec 2015 20:31:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151214043159.8357.38315.idtracker@ietfa.amsl.com> Date: Sun, 13 Dec 2015 20:31:59 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-proof-of-possession-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 04:32:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) Authors : Michael B. Jones John Bradley Hannes Tschofenig Filename : draft-ietf-oauth-proof-of-possession-09.txt Pages : 18 Date : 2015-12-13 Abstract: This specification defines how to express a declaration in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular key and that the recipient can cryptographically confirm proof-of- possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-proof-of-possession-09 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Dec 13 20:33:12 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED191A913A for ; Sun, 13 Dec 2015 20:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKPq4EIh1-HX for ; Sun, 13 Dec 2015 20:33:07 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0121.outbound.protection.outlook.com [207.46.100.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 762941A913D for ; Sun, 13 Dec 2015 20:33:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=upKRHfXJP3dXVbe2Zp/bY8nPOhF65UxCREnIVlJjkfA=; b=W8JkoaFBkXUzs7B9U0wZCQhe5vXxZBJXcMjKIVnGimNnGlqIU0vCSXGgrQFHT9InWtQ3Puigl6SHbOV4FMDBelGPjTDLgYiK2cVz+dKnQCZK9ZQj+Coa88Xkv7sEbNkNyefWNXfFguuKqXYRu7OK7dQh6iyly/GyoNauXrLVRk0= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.355.16; Mon, 14 Dec 2015 04:33:05 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0355.012; Mon, 14 Dec 2015 04:33:05 +0000 From: Mike Jones To: Kathleen Moriarty Thread-Topic: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-possession Thread-Index: AQHRNiU1IGc6XVuMlEWvFje82tqI857J5K9w Date: Mon, 14 Dec 2015 04:33:04 +0000 Message-ID: References: <255B9BB34FB7D647A506DC292726F6E13BB4EA5AD2@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [188.92.133.18] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:OA9w8LTSn98MRqIuiEnxsmaU8u5Y+saTQZW4O9609Y22kecL0HI31OlIFwp1lv7TR068aY8/hANNKJmY+CmhRqie560wbGdK3hAW8kiVbVJrECXJ0Tbyd4UuqeBlvBmqB3DKkip057MCZC2hOqk9RQ==; 24:GH2QfD3tIQ9CciJ5xBKvh24drwHfUJ3t2DsQvbowvZ+u5V6CsARPUlmd9rvdrUQjcQ4D92ymrU0mpbpvds8M54DDNwGgrOm4poJZXUd4hW0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 0790FB1F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(52604005)(43784003)(199003)(24454002)(189002)(377454003)(13464003)(74316001)(16601075003)(5002640100001)(2950100001)(93886004)(33656002)(5003600100002)(2900100001)(92566002)(15975445007)(101416001)(102836003)(10090500001)(6116002)(3846002)(5008740100001)(230783001)(5004730100002)(77096005)(586003)(1096002)(10290500002)(66066001)(10400500002)(106116001)(105586002)(1220700001)(99286002)(8990500004)(54356999)(11100500001)(86362001)(5005710100001)(122556002)(50986999)(40100003)(19580405001)(97736004)(5001960100002)(87936001)(81156007)(19580395003)(110136002)(189998001)(76176999)(106356001)(86612001)(76576001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2015 04:33:04.9648 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 04:33:11 -0000 RG9uZSBpbiAtMDkuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBLYXRobGVl biBNb3JpYXJ0eSBbbWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tXSANClNl bnQ6IFN1bmRheSwgRGVjZW1iZXIgMTMsIDIwMTUgODowOSBQTQ0KVG86IE1pa2UgSm9uZXMgPE1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4NCkNjOiBNYW5nZXIsIEphbWVzIDxKYW1lcy5ILk1h bmdlckB0ZWFtLnRlbHN0cmEuY29tPjsgb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FV VEgtV0ddIGltcGxlbWVudGF0aW9ucyBvZiBkcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nl c3Npb24NCg0KSSBqdXN0IGFkZGVkIHRoZSBiYWxsb3QgZm9yIHRoZXNlIGRyYWZ0cywgY2FuIHRo aXMgYmUgZml4ZWQgcXVpY2tseT8NCg0KVGhhbmtzLg0KS2F0aGxlZW4NCg0KT24gU3VuLCBEZWMg MTMsIDIwMTUgYXQgMTE6MDcgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbT4gd3JvdGU6DQo+IEdvb2QgZXllLCBKYW1lcyEgIFRoYW5rcyBmb3IgY2F0Y2hpbmcgdGhp cy4gIEnigJlsbCBmaXggaXQgcmlnaHQgYXdheS4NCj4NCj4NCj4NCj4gSXQgdHVybnMgb3V0IHRo YXQgZXhhbXBsZXMgYXJlIGJhc2VkIG9uIHRoZSB0cmFjZSBjYXB0dXJlZCBpbiBGZWJydWFyeSAN Cj4gMjAxMyDigJMgd2VsbCBiZWZvcmUgdGhlIFhib3ggT25lIGxhdW5jaCBpbiBOb3ZlbWJlciAy MDEzLiAgSeKAmWQgYWN0dWFsbHkgDQo+IG5vdGljZWQgdGhpcyB0aGVuIGFuZCBoYWQgWGJveCBj b3JyZWN0IHRoZWlyIGNvZGUuICBCdXQgc2lsbHkgbWUsIEkgDQo+IGZhaWxlZCB0byB1bmlmb3Jt bHkgY29ycmVjdCBpdCBpbiB0aGUgZHJhZnQuDQo+DQo+DQo+DQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGFua3MgYWdhaW4hDQo+ DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAtLSBNaWtlDQo+DQo+DQo+DQo+IEZyb206IE1hbmdlciwgSmFtZXMgW21haWx0bzpKYW1l cy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tXQ0KPiBTZW50OiBTdW5kYXksIERlY2VtYmVyIDEz LCAyMDE1IDg6MDQgUE0NCj4gVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbT47IEthdGhsZWVuIE1vcmlhcnR5IA0KPiA8a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFp bC5jb20+OyBvYXV0aEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW09BVVRILVdHXSBpbXBsZW1l bnRhdGlvbnMgb2YgDQo+IGRyYWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbg0KPg0K Pg0KPg0KPiBUaGF0IHZhbHVlIHVzZXMgc3RyaW5ncyBmb3IgZXhwaXJ5IGFuZCBub3QtYmVmb3Jl IGRhdGVzIHNvIGl0IGlzIG5vdCBhIA0KPiB2YWxpZCBKV1Q7IHRoZXNlIGRhdGVzIG5lZWQgdG8g YmUgbnVtYmVycy4NCj4NCj4NCj4NCj4gMyBvZiB0aGUgZXhhbXBsZXMgaW4gZHJhZnQtaWV0Zi1v YXV0aC1wcm9vZi1vZi1wb3NzZXNzaW9uIGFyZSANCj4gc2ltaWxhcmx5IGludmFsaWQgKOKAnGV4 cOKAnSBhbmQg4oCcaWF04oCdKTsgMSBleGFtcGxlIGdldHMgaXQgcmlnaHQuDQo+DQo+DQo+DQo+ IC0tDQo+DQo+IEphbWVzIE1hbmdlcg0KPg0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBNaWtlIEpvbmVzDQo+IFNlbnQ6IE1vbmRheSwgMTQgRGVjZW1iZXIgMjAxNSAyOjQw IFBNDQo+IFRvOiBLYXRobGVlbiBNb3JpYXJ0eSA8a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFp bC5jb20+OyANCj4gb2F1dGhAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gaW1w bGVtZW50YXRpb25zIG9mIA0KPiBkcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Npb24N Cj4NCj4NCj4NCj4gWWVzLiAgWGJveCBPbmUgYW5kIGl0cyBwYXJ0bmVycyBoYXZlIGJlZW4gdXNp bmcgdGhpcyBzaW5jZSBpdHMgbGF1bmNoLiAgDQo+IFRoZSBmb2xsb3dpbmcgdG9rZW4gY2xhaW1z IGFyZSBmcm9tIGEgcHJvZHVjdGlvbiB0cmFjZSBjYXB0dXJlZCBpbiBlYXJseSAyMDEzOg0KPg0K Pg0KPg0KPiAgIHsNCj4NCj4gICAgImlzcyI6Inhhcy54Ym94bGl2ZS5jb20iLA0KPg0KPiAgICAi YXVkIjoiaHR0cDovL2F1dGgueGJveGxpdmUuY29tIiwNCj4NCj4gICAgImV4cCI6IjEzNjEzOTg4 MjQiLA0KPg0KPiAgICAibmJmIjoiMTM2MDE4OTIyNCIsDQo+DQo+ICAgICJjbmYiOnsNCj4NCj4g ICAgICAiandrIjp7DQo+DQo+ICAgICAgICAia3R5IjoiRUMiLA0KPg0KPiAgICAgICAgInVzZSI6 InNpZyIsDQo+DQo+ICAgICAgICAiY3J2IjoiUC0yNTYiLA0KPg0KPiAgICAgICAgIngiOiIxOHdI TGVJZ1c5d1ZONlZEMVR4Z3BxeTJMc3pZa01mNko4bmpWQWlidmhNIiwNCj4NCj4gICAgICAgICJ5 IjoiLVY0ZFM0VWFMTWdQXzRmWTRqOGlyN2NsMVRYbEZkQWdjeDU1bzdUa2NTQSINCj4NCj4gICAg ICAgfQ0KPg0KPiAgICAgfQ0KPg0KPiAgIH0NCj4NCj4NCj4NCj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIA0KPiBNaWtl DQo+DQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+DQo+IEZyb206IE9BdXRo IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEthdGhsZWVuIA0K PiBNb3JpYXJ0eQ0KPg0KPiBTZW50OiBTdW5kYXksIERlY2VtYmVyIDEzLCAyMDE1IDc6MTQgUE0N Cj4NCj4gVG86IG9hdXRoQGlldGYub3JnDQo+DQo+IFN1YmplY3Q6IFtPQVVUSC1XR10gaW1wbGVt ZW50YXRpb25zIG9mIA0KPiBkcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Npb24NCj4N Cj4NCj4NCj4gSGksDQo+DQo+DQo+DQo+IEFyZSB0aGVyZSBhbnkgaW1wbGVtZW50YXRpb25zIG9m ICBkcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Npb24/DQo+DQo+DQo+DQo+IFRoYW5r cyENCj4NCj4NCj4NCj4gLS0NCj4NCj4NCj4NCj4gQmVzdCByZWdhcmRzLA0KPg0KPiBLYXRobGVl bg0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPg0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4NCj4gT0F1dGhAaWV0Zi5vcmcNCj4NCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPg0KPg0KPg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0KPiBPQXV0 aCBtYWlsaW5nIGxpc3QNCj4NCj4gT0F1dGhAaWV0Zi5vcmcNCj4NCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KLS0gDQoNCkJlc3QgcmVnYXJkcywN CkthdGhsZWVuDQo= From nobody Sun Dec 13 21:16:27 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A501AC41C for ; Sun, 13 Dec 2015 21:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LS7JjOM3_kGb for ; Sun, 13 Dec 2015 21:16:21 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0C31AC422 for ; Sun, 13 Dec 2015 21:16:20 -0800 (PST) Received: by qkck189 with SMTP id k189so84408228qkc.0 for ; Sun, 13 Dec 2015 21:16:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zde3mt8eTrvk7TvMV/2Lj4WZsJcSr+iR6jhOIp0e/U8=; b=WD0yfYCnXKk40bHutDSar3EQUucp1Wo5CGkkY2JkuRsGkt+i1ymLYHiqmb27oAtOEE 8yJheU8worOCI1ZxotnAPxxl0/srw7lTSh70HBxkL2300fuNSw0Tzj9eEhrT/Pdu7xNZ WKfROhvcdLcO0DKQ3iK4ILoYx1X32CNb+LrF19bCLo5vQkTb7OF1DgnaMMi5+GVUuTcB XQq/R5Q1bxC12PzOyzReT6Vs8MRSjGsO9lHYpxWyn99H2plHEZhiazZ0Hf2rHMZIYc/e E6jKkjzbtXMTWVS0CQZRJn6kMxOZALpSKGM9zvBSskD6oGefOx5Fm9b07XUsx1mdZxQN MPFQ== X-Received: by 10.55.79.15 with SMTP id d15mr1646433qkb.17.1450070180065; Sun, 13 Dec 2015 21:16:20 -0800 (PST) Received: from [172.20.1.204] ([65.200.157.66]) by smtp.gmail.com with ESMTPSA id e80sm10025183qkj.30.2015.12.13.21.16.18 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Dec 2015 21:16:19 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: Date: Mon, 14 Dec 2015 00:16:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <71106BB0-14DC-43F6-A057-D584B08366AF@gmail.com> References: <255B9BB34FB7D647A506DC292726F6E13BB4EA5AD2@WSMSG3153V.srv.dir.telstra.com> To: Mike Jones Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 05:16:24 -0000 Thank you! Sent from my iPhone > On Dec 13, 2015, at 11:33 PM, Mike Jones wro= te: >=20 > Done in -09. >=20 > -----Original Message----- > From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]=20 > Sent: Sunday, December 13, 2015 8:09 PM > To: Mike Jones > Cc: Manger, James ; oauth@ietf.org > Subject: Re: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-posse= ssion >=20 > I just added the ballot for these drafts, can this be fixed quickly? >=20 > Thanks. > Kathleen >=20 >> On Sun, Dec 13, 2015 at 11:07 PM, Mike Jones wrote: >> Good eye, James! Thanks for catching this. I=E2=80=99ll fix it right aw= ay. >>=20 >>=20 >>=20 >> It turns out that examples are based on the trace captured in February=20= >> 2013 =E2=80=93 well before the Xbox One launch in November 2013. I=E2=80= =99d actually=20 >> noticed this then and had Xbox correct their code. But silly me, I=20 >> failed to uniformly correct it in the draft. >>=20 >>=20 >>=20 >> Thanks again! >>=20 >> -- Mike >>=20 >>=20 >>=20 >> From: Manger, James [mailto:James.H.Manger@team.telstra.com] >> Sent: Sunday, December 13, 2015 8:04 PM >> To: Mike Jones ; Kathleen Moriarty=20 >> ; oauth@ietf.org >> Subject: RE: [OAUTH-WG] implementations of=20 >> draft-ietf-oauth-proof-of-possession >>=20 >>=20 >>=20 >> That value uses strings for expiry and not-before dates so it is not a=20= >> valid JWT; these dates need to be numbers. >>=20 >>=20 >>=20 >> 3 of the examples in draft-ietf-oauth-proof-of-possession are=20 >> similarly invalid (=E2=80=9Cexp=E2=80=9D and =E2=80=9Ciat=E2=80=9D); 1 ex= ample gets it right. >>=20 >>=20 >>=20 >> -- >>=20 >> James Manger >>=20 >>=20 >>=20 >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones >> Sent: Monday, 14 December 2015 2:40 PM >> To: Kathleen Moriarty ;=20 >> oauth@ietf.org >> Subject: Re: [OAUTH-WG] implementations of=20 >> draft-ietf-oauth-proof-of-possession >>=20 >>=20 >>=20 >> Yes. Xbox One and its partners have been using this since its launch. =20= >> The following token claims are from a production trace captured in early 2= 013: >>=20 >>=20 >>=20 >> { >>=20 >> "iss":"xas.xboxlive.com", >>=20 >> "aud":"http://auth.xboxlive.com", >>=20 >> "exp":"1361398824", >>=20 >> "nbf":"1360189224", >>=20 >> "cnf":{ >>=20 >> "jwk":{ >>=20 >> "kty":"EC", >>=20 >> "use":"sig", >>=20 >> "crv":"P-256", >>=20 >> "x":"18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM", >>=20 >> "y":"-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA" >>=20 >> } >>=20 >> } >>=20 >> } >>=20 >>=20 >>=20 >> --=20 >> Mike >>=20 >>=20 >>=20 >> -----Original Message----- >>=20 >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen=20 >> Moriarty >>=20 >> Sent: Sunday, December 13, 2015 7:14 PM >>=20 >> To: oauth@ietf.org >>=20 >> Subject: [OAUTH-WG] implementations of=20 >> draft-ietf-oauth-proof-of-possession >>=20 >>=20 >>=20 >> Hi, >>=20 >>=20 >>=20 >> Are there any implementations of draft-ietf-oauth-proof-of-possession? >>=20 >>=20 >>=20 >> Thanks! >>=20 >>=20 >>=20 >> -- >>=20 >>=20 >>=20 >> Best regards, >>=20 >> Kathleen >>=20 >>=20 >>=20 >> _______________________________________________ >>=20 >> OAuth mailing list >>=20 >> OAuth@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> _______________________________________________ >>=20 >> OAuth mailing list >>=20 >> OAuth@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen From nobody Sun Dec 13 23:57:56 2015 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E65931A0162; Sun, 13 Dec 2015 23:57:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151214075753.30560.24391.idtracker@ietfa.amsl.com> Date: Sun, 13 Dec 2015 23:57:53 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 07:57:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Token Exchange: An STS for the REST of Us Authors : Michael B. Jones Anthony Nadalin Brian Campbell John Bradley Chuck Mortimore Filename : draft-ietf-oauth-token-exchange-03.txt Pages : 28 Date : 2015-12-13 Abstract: This specification defines a protocol for a lightweight HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-03 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 14 00:05:52 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E331A020B for ; Mon, 14 Dec 2015 00:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rw_FTsFBsJJl for ; Mon, 14 Dec 2015 00:05:46 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0784.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:784]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9CAE1A01FC for ; Mon, 14 Dec 2015 00:05:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Q+Xszt+obUq19VYavgEhY43nyTmp80ySOzXAi+UzGDk=; b=Iy8RowCI7NDIAEkrnNU+uB5WI/MUDgYqOV36ly5rnxjUTscVDzbLWsYEknfn+0XzvzoiQmqiRmyGN55KPk0Pj8cuvvIU3Tx1i09O2xw8ENF4bs7NAHTVaPCesPDL293ke07bVvedG7EPGQsvvKIzpmUT2AxNs8unjeyycTZv9/g= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.355.16; Mon, 14 Dec 2015 08:05:29 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0355.012; Mon, 14 Dec 2015 08:05:29 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth 2.0 Token Exchange: An STS for the REST of Us Thread-Index: AdE2QTL6bORc7Ai2To2NOnDbcDUZsg== Date: Mon, 14 Dec 2015 08:05:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [188.92.133.18] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:7c/lgc+wP3J4eFvG99LeSST9rPWbyjK/9FKexO38djDBQg/8KFraMdq8YGLd76ZJsgK+i8rhgKqvGo3M9FWuOj86epF+iiFoRL51918RDozhn0mSbURS/BtSnnCbW0R/Wn+28rgwR/VmiIwqoW8h2g==; 24:lEGquN2Zwo4QZ07V/7JRTcmeNYX4ruTitFcbZ6wb1h3kATvsp2U62SOV+RQf2bEfqfu5fZd1g6ROWSbqeveuv5jNluMQw0iR44qRDVfajTo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 0790FB1F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(54164003)(199003)(189002)(74316001)(19625215002)(2501003)(450100001)(16236675004)(33656002)(2900100001)(5003600100002)(5002640100001)(92566002)(15975445007)(77096005)(790700001)(102836003)(10090500001)(101416001)(6116002)(2351001)(3846002)(586003)(5004730100002)(5008740100001)(19617315012)(229853001)(10290500002)(66066001)(10400500002)(105586002)(1220700001)(99286002)(19300405004)(8990500004)(54356999)(76576001)(11100500001)(86362001)(5005710100001)(122556002)(40100003)(50986999)(1730700002)(97736004)(5001960100002)(107886002)(81156007)(19580395003)(110136002)(87936001)(189998001)(86612001)(1096002)(106356001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442F1857A7B1936D83F18DCF5ED0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2015 08:05:28.8665 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Subject: [OAUTH-WG] OAuth 2.0 Token Exchange: An STS for the REST of Us X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 08:05:51 -0000 --_000_BY2PR03MB442F1857A7B1936D83F18DCF5ED0BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm happy to report that a substantially revised OAuth 2.0 Token Exchange d= raft has been published that enables a broad range of use cases, while stil= l remaining as simple as possible. This draft unifies the approaches taken= in the previous working group draft and draft-campbell-oauth-sts, incorpor= ating working group input from the in-person discussions in Prague and mail= ing list discussions. Thanks to all for your interest in and contributions= to OAuth Token Exchange! Brian Campbell deserves special recognition for = doing much of the editing heavy lifting for this draft. The core functionality remains token type independent. That said, new clai= ms are also defined to enable representation of delegation actors in JSON W= eb Tokens (JWTs). Equivalent claims could be defined for other token types= by other specifications. See the Document History section for a summary of the changes made. Please= check it out! The specification is available at: * http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-token-exchange-03.htm= l -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1509 and as= @selfissued. --_000_BY2PR03MB442F1857A7B1936D83F18DCF5ED0BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m happy to report that a substantially revis= ed OAuth 2.0 Token Exchange draft has been published that enables a broad r= ange of use cases, while still remaining as simple as possible.  This = draft unifies the approaches taken in the previous working group draft and draft-campbell-oauth-sts, incorporating working gr= oup input from the in-person discussions in Prague and mailing list discuss= ions.  Thanks to all for your interest in and contributions to OAuth T= oken Exchange!  Brian Campbell deserves special recognition for doing much of the editing heavy lifting for this d= raft.

 

The core functionality remains token type independen= t.  That said, new claims are also defined to enable representation of= delegation actors in JSON Web Tokens (JWTs).  Equivalent claims could= be defined for other token types by other specifications.

 

See the Document History section for a summary of th= e changes made.  Please check it out!

 

The specification is available at:

·       http://tools.ietf.org/html/draft-ietf-oauth-t= oken-exchange-03

 

An HTML-formatted version is also available at:=

·       http://self-issued.info/docs/draft-iet= f-oauth-token-exchange-03.html

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           -- Mike

 

P.S.  This note was also posted at http://self-issued.info/?p=3D1509 and as @selfissued.

--_000_BY2PR03MB442F1857A7B1936D83F18DCF5ED0BY2PR03MB442namprd_-- From nobody Mon Dec 14 09:54:56 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027781AD0BB for ; Mon, 14 Dec 2015 09:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.491 X-Spam-Level: X-Spam-Status: No, score=0.491 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1g048OmU8kf for ; Mon, 14 Dec 2015 09:54:51 -0800 (PST) Received: from nm15.bullet.mail.bf1.yahoo.com (nm15.bullet.mail.bf1.yahoo.com [98.139.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D79861ACE8D for ; Mon, 14 Dec 2015 09:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1450115689; bh=n3qsd7BFotG//zoMbLo8WH5907C8x5sSq5Px5REiUPQ=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=qqEGGHitjlhbl7vReILIeYwuzve8IpiROXxtgmEFGV1Tuhq928ABdQAnKM71aCvv4/TCm9AagMwUfBHW3WYyDy6agdQwa0YEft0XktSwAFIyHwYy2T/Hr0OQqueJqemxWA24dkg+oc2fztTM7UZyfgP4fMkDTYK7PwGwKC2WF0p9xSLafXubC2hlTgY3Xhq5QqS/x/xaQl1e0nmj6X1fk57ec+eAI4lcgNvkOOpe65evyreBXt7qsMHjS0Dzpsa9FUYa8oDbDYhNgY66nCDxtp2USUoS7gFktbmHjs3lb/J32LptxECuh7LIcJ+0I8n9fC33ni8gaW07wZJz01RL+w== Received: from [66.196.81.173] by nm15.bullet.mail.bf1.yahoo.com with NNFMP; 14 Dec 2015 17:54:49 -0000 Received: from [98.139.212.232] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 14 Dec 2015 17:54:49 -0000 Received: from [127.0.0.1] by omp1041.mail.bf1.yahoo.com with NNFMP; 14 Dec 2015 17:54:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 893298.27895.bm@omp1041.mail.bf1.yahoo.com X-YMail-OSG: ihia6nIVM1lURd7qt2rAnfogQNkzQCgxoW435fPlrun8mStCN3KZeQIcLL9i5Yb uVrhPDS9gxVdRd2DHZ6bZ7y99XhXbxYB1bZmohgpR69l5CQDJ7LOnF7o9GAe7_g44Qn2gh9tAAKE mV7_IMTuLJYWI6IASoSAR6smXtSHP40gaoBpG4USSfRArYEX7cQf1.ykpvoW0xURxQ4fq14wjTHm lJjoAbh5f9Jq5aC1A5h.1._GqfsDpcVjjoVUqrAlLq4Icws1LPz8kzfRnLNDOyboYVM0YtKzRDzx 1jPFV0jNYqGuAqrF0IqZUuB6FgWejbafwwGno3Q6IHSZAbmr0kYxykbnNdM9BqPTZmb0btqb9l6P 5qtdNkwjRGWt.6cd0AM3srP7EPnHfmZs_k6ls3_IuNd7wSkPmMqJkmJacB5sXiihuCNtRSQLzalz 2GXPrJj1iMTHROsKxz.iAr43PSxG4jjRDtTURWMEkfsmXf_g_fmNsnYldvkx85v4zZb8HnXk4qvi Q.AkpsyvXM4A- Received: by 66.196.81.119; Mon, 14 Dec 2015 17:54:49 +0000 Date: Mon, 14 Dec 2015 17:54:49 +0000 (UTC) From: Bill Mills To: Torsten Lodderstedt , Mike Jones , "oauth@ietf.org" , Nat Sakimura , John Bradley Message-ID: <1588345494.990701.1450115689093.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <566DD856.1010603@lodderstedt.net> References: <566DD856.1010603@lodderstedt.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_990700_863714657.1450115689082" Archived-At: Subject: Re: [OAUTH-WG] OAuth Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 17:54:54 -0000 ------=_Part_990700_863714657.1450115689082 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think it is more likely that the flow for the user will be that they know= an RS and the RS provides some reference to the AS. =C2=A0The RS might wel= l consume a generic lookup flow though. =C2=A0We do need the "updated webfi= nger thing" for users as a generic though. The WF type thing for a generic user lookup in a domain might be used for d= iscovering the SMTP/IMAP/webmail entrypoints for a user along with the AS a= nd that's another possible useful thing. =C2=A0User specific rather than ap= parently server/service specific.=20 On Sunday, December 13, 2015 12:59 PM, Torsten Lodderstedt wrote: =20 Hi Mike, Nat, John, =20 thanks for starting this work.=20 =20 It seems you assume the AS can always be discoverd using the user id of th= e resource owner. I think the underlying assumption is resource servers acc= ept access token of different (any?) user specific AS (and OP)? From my per= spective, RSs nowadays typically trust _the_ AS of their security domain/ec= osystem and all resource owners need to have an user account with this part= icular AS. So I would assume the process to start at the RS. We potentially= need to cover for both cases.=20 =20 What do you think? =20 best regards, Torsten. =20 Am 26.11.2015 um 00:37 schrieb Mike Jones: =20 =20 #yiv5368577927 #yiv5368577927 -- _filtered #yiv5368577927 {font-family:Wing= dings;panose-1:5 0 0 0 0 0 0 0 0 0;} _filtered #yiv5368577927 {panose-1:2 4= 5 3 5 4 6 3 2 4;} _filtered #yiv5368577927 {font-family:Calibri;panose-1:2= 15 5 2 2 2 4 3 2 4;} _filtered #yiv5368577927 {panose-1:2 11 5 2 4 2 4 2 2= 3;}#yiv5368577927 #yiv5368577927 p.yiv5368577927MsoNormal, #yiv5368577927 = li.yiv5368577927MsoNormal, #yiv5368577927 div.yiv5368577927MsoNormal {margi= n:0in;margin-bottom:.0001pt;font-size:11.0pt;}#yiv5368577927 a:link, #yiv53= 68577927 span.yiv5368577927MsoHyperlink {color:#0563C1;text-decoration:unde= rline;}#yiv5368577927 a:visited, #yiv5368577927 span.yiv5368577927MsoHyperl= inkFollowed {color:#954F72;text-decoration:underline;}#yiv5368577927 pre {m= argin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv5368577927 p.yiv53685= 77927MsoListParagraph, #yiv5368577927 li.yiv5368577927MsoListParagraph, #yi= v5368577927 div.yiv5368577927MsoListParagraph {margin-top:0in;margin-right:= 0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;font-size:11.0= pt;}#yiv5368577927 span.yiv5368577927EmailStyle17 {color:windowtext;}#yiv53= 68577927 span.yiv5368577927HTMLPreformattedChar {}#yiv5368577927 span.yiv53= 68577927grey {}#yiv5368577927 .yiv5368577927MsoChpDefault {} _filtered #yiv= 5368577927 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv5368577927 div.yiv536857792= 7WordSection1 {}#yiv5368577927 _filtered #yiv5368577927 {} _filtered #yiv53= 68577927 {font-family:Symbol;} _filtered #yiv5368577927 {} _filtered #yiv53= 68577927 {font-family:Wingdings;} _filtered #yiv5368577927 {font-family:Sym= bol;} _filtered #yiv5368577927 {} _filtered #yiv5368577927 {font-family:Win= gdings;} _filtered #yiv5368577927 {font-family:Symbol;} _filtered #yiv53685= 77927 {} _filtered #yiv5368577927 {font-family:Wingdings;}#yiv5368577927 ol= {margin-bottom:0in;}#yiv5368577927 ul {margin-bottom:0in;}#yiv5368577927 = I=E2=80=99m pleased to announce that Nat Sakimura, John Bradley, and I have= created an OAuth 2.0 Discovery specification.=C2=A0 This fills a hole in t= he current OAuth specification set that is necessary to achieve interoperab= ility.=C2=A0 Indeed, the Interoperability section of OAuth 2.0 states: In a= ddition, this specification leaves a few required components partially or f= ully undefined (e.g., client registration, authorization server capabilitie= s, endpoint discovery).=C2=A0 Without these components, clients must be man= ually and specifically configured against a specific authorization server a= nd resource server in order to interoperate. =C2=A0 This framework was des= igned with the clear expectation that future work will define prescriptive = profiles and extensions necessary to achieve full web-scale interoperabilit= y. =C2=A0 This specification enables discovery of both endpoint locations = and authorization server capabilities. =C2=A0 This specification is based = upon the already widely deployed OpenID Connect Discovery 1.0 specification= and is compatible with it, by design.=C2=A0 The OAuth Discovery spec remov= es the portions of OpenID Connect Discovery that are OpenID specific and ad= ds metadata values for Revocation and Introspection endpoints.=C2=A0 It al= so maps OpenID concepts, such as OpenID Provider, Relying Party, End-User, = and Issuer to their OAuth underpinnings, respectively Authorization Server= , Client, Resource Owner, and the newly introduced Configuration Informatio= n Location. =C2=A0Some identifiers with names that appear to be OpenID spec= ific were retained for compatibility purposes; despite the reuse of these i= dentifiers that appear to be OpenID specific, their usage in this specifica= tion is actually referring to general OAuth 2.0 features that are not speci= fic to OpenID Connect. =C2=A0 The specification is available at: =C2=B7=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/dr= aft-jones-oauth-discovery-00 =C2=A0 An HTML-formatted version is also avai= lable at: =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://sel= f-issued.info/docs/draft-jones-oauth-discovery-00.html =C2=A0 =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike = =C2=A0 P.S.=C2=A0 This note was also posted at http://self-issued.info/?p= =3D1496 and as @selfissued. =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_990700_863714657.1450115689082 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think it is more likely that the fl= ow for the user will be that they know an RS and the RS provides some refer= ence to the AS.  The RS might well consume a generic lookup flow thoug= h.  We do need the "updated webfinger thing" for users as a generic th= ough.

The WF type thing for a ge= neric user lookup in a domain might be used for discovering the SMTP/IMAP/w= ebmail entrypoints for a user along with the AS and that's another possible= useful thing.  User specific rather than apparently server/service sp= ecific.



On Sunday, December 13, 2015 12:5= 9 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
=


<= div> Hi Mike, Nat, John,

thanks for starting this work.

It seems you assume the AS can always be discoverd using the user id of the resource owner. I think the underlying assumption is resource servers accept access token of different (any?) user specific AS (and OP)? From my perspective, RSs nowadays typically trust _the_ AS of their security domain/ecosystem and all resource owners need to have an user account with this particular AS. So I would assume the process to start at the RS. We potentially need to cover for both cases.

What do you think?

best regards,
Torsten.

Am 26.11.2015 um 00:37 schr= ieb Mike Jones:
I=E2=80=99m pleased to announ= ce that Nat Sakimura, John Bradley, and I have created an OAuth 2.0 Discovery specification.  This fills a hole in the current OAuth specification set that is necessary to achieve interoperability.  Indeed, the Interoperability section of OAuth 2.0 states:
=20 
In addition, this specification leaves a few required component=
s partially or fully undefined (e.g., client registration, authorization se=
rver capabilities, endpoint discovery).  Without these components, cli=
ents must be manually and specifically configured against a specific author=
ization server and resource server in order to interoperate.
= =20 
  
=20 
This framework was designed with the clear expectation that fut=
ure work will define prescriptive profiles and extensions necessary to achi=
eve full web-scale interoperability.
=20
 
=20
This specif= ication enables discovery of both endpoint locations and authorization server capabilities.
=20
 
=20
This specif= ication is based upon the already widely deployed OpenID Connect Discovery 1.0 specification and is compatible with it, by design.  The OAuth Discovery spec removes the portions of OpenID Connect Discovery that are OpenID specific and adds metadata values for Revocation and Introspection endpoints.  It also maps OpenID concepts, su= ch as OpenID Provider, Relying Party, End-User, and Issuer to their OAuth underpinnings, respectively Authorization Server, Client, Resource Owner, and the newly introduced Configuration Information Location.  Some identifiers with names that appear to be OpenID specific were retained for compatibility purposes; despite the reuse of these identifiers that appear to be OpenID specific, their usage in this specification is actually referring to general OAuth 2.0 features that are not specific to OpenID Connect.=20
 
=20
The specifi= cation is available at:
=20
=C2=B7         http://tools.ietf.org/html/draft-= jones-oauth-discovery-00
=20
 
=20
An HTML-for= matted version is also available at:
=20
=C2=B7         http://self-issued.info/docs/= draft-jones-oauth-discovery-00.html=20
 
=20
  = ;            &n= bsp;           &nb= sp;            =             &nb= sp;            -- Mi= ke
=20
 
=20
P.S.  = This note was also posted at http://self-issued.info/?p=3D1496 and as @selfissued.
=20 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=20

____________= ___________________________________
OAuth mailing listOAuth@ietf.org
= https://www.ietf.org/mailman/listinfo/oauth

------=_Part_990700_863714657.1450115689082-- From nobody Tue Dec 15 06:45:51 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312CD1A8A51 for ; Tue, 15 Dec 2015 06:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1PQa3YdLICd for ; Tue, 15 Dec 2015 06:45:47 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:737]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 899D41A8A4C for ; Tue, 15 Dec 2015 06:45:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=J4Lu+I18YqcPSIrDR4EMku1TkTfQIgP2CoWgJopcUNI=; b=ZPWVZX09UVvxB4Yey6G88ZmqY36KKWxgcTpppFaRvfXGwjYxutxk71eoqYjZtWP3PLFnFImntNYuobM2tvIHcybx3Q3X5GyBM//p3HPUBkHBG+7MMkmcVKX3h02PSPNedr8yAASd3OWG27cX/K7ihZr3Cbdc1wqP5EbcFKHL55o= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.355.16; Tue, 15 Dec 2015 14:45:27 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0355.012; Tue, 15 Dec 2015 14:45:27 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Authentication Method Reference Values coordination with OpenID MODRNA Thread-Index: AdE3Q7yGnw8bjmL7TkqPt3a9WweCpw== Date: Tue, 15 Dec 2015 14:45:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [87.157.192.116] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:aQaTc2sx0N96byDy5OmThnQ2WtEyrmp0mGqT6sMzRnjmynuntuyCi0cSjE+jEO9CZQUei2BTf+bKoKu7pl53jjnamzMsK7TK/VE2LQdgyKFiksjQq6irwNCgXGUgl/4DjYq48kOv6IyMSckgYSRSyA==; 24:d0yhN8PeYygdxhotinJzA+DlK5gR26C/c+g21QapT/lqSlZY1e/gGYxZaaouyLbZKia1VfERb5ZhKI4Lvb2Nv/9rkUq+woe3eWLJWDQ/fMI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 07915F544A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(199003)(189002)(189998001)(50986999)(15975445007)(450100001)(97736004)(54356999)(87936001)(2900100001)(81156007)(3846002)(6116002)(586003)(1096002)(2501003)(1730700002)(102836003)(1220700001)(122556002)(76576001)(40100003)(790700001)(77096005)(92566002)(99286002)(11100500001)(107886002)(74316001)(106356001)(19580395003)(101416001)(10290500002)(5002640100001)(105586002)(5001960100002)(5008740100001)(86362001)(66066001)(16236675004)(229853001)(10090500001)(110136002)(33656002)(86612001)(2351001)(15395725005)(19625215002)(5004730100002)(19300405004)(5003600100002)(5005710100001)(19617315012)(8990500004)(10400500002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4428374827C420899C94BDDF5EE0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2015 14:45:27.1926 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Subject: [OAUTH-WG] Authentication Method Reference Values coordination with OpenID MODRNA X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 14:45:49 -0000 --_000_BY2PR03MB4428374827C420899C94BDDF5EE0BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authentication Method Reference Values draft -04 added the values "face" (f= acial recognition), "geo" (geolocation), "hwk" (proof-of-possession of a ha= rdware-secured key), "pin" (Personal Identification Number or pattern), and= "swk" (proof-of-possession of a software-secured key), and removed the val= ue "pop" (proof-of-possession), based on input from members of the OpenID F= oundation MODRNA working group. The specification is available at: * http://tools.ietf.org/html/draft-jones-oauth-amr-values-04 An HTML formatted version is also available at: * http://self-issued.info/docs/draft-jones-oauth-amr-values-04.html -- Mike P.S. This note was also posted at http= ://self-issued.info/?p=3D1511 and as @selfissued. --_000_BY2PR03MB4428374827C420899C94BDDF5EE0BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Authentication Method Reference Va= lues draft -04 added the values “face” (fa= cial recognition), “geo” (geolocation), “hwk” (proof-of-possession= of a hardware-secured key), “pin” (Person= al Identification Number or pattern), and “swk” (proof-of-p= ossession of a software-secured key), and removed the value “<= span lang=3D"EN" style=3D"font-family:"Courier New"">pop” (proof-of-possession), based on input from members of the OpenID Foundation MODRNA working group.

 

The specification is available at:

·       http://tools.ietf.org/html/draft-jones-oauth-amr= -values-04

 

An HTML formatted version is also available at:=

·       http://self-issued.info/docs/draft-jones-= oauth-amr-values-04.html

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

P.S.  This note was also posted at http://self-issued.info/?= p=3D1511 and as @selfissued.

 

 

--_000_BY2PR03MB4428374827C420899C94BDDF5EE0BY2PR03MB442namprd_-- From nobody Tue Dec 15 08:00:51 2015 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC0B1A902B for ; Tue, 15 Dec 2015 08:00:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151215160050.26932.29080.idtracker@ietfa.amsl.com> Date: Tue, 15 Dec 2015 08:00:50 -0800 From: IETF Secretariat Archived-At: Subject: [OAUTH-WG] Milestones changed for oauth WG X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 16:00:50 -0000 Changed milestone "Submit 'Request by JWS ver.1.0 for OAuth 2.0' to the IESG for consideration as a Proposed Standard", set due date to February 2016 from September 2015. Changed milestone "Submit 'Proof-of-Possession OAuth Security' document bundle for consideration as a Proposed Standard", set due date to April 2016 from October 2015. Changed milestone "Submit 'OAuth 2.0 Token Exchange' to the IESG for consideration as a Proposed Standard", set due date to July 2016 from August 2015. URL: https://datatracker.ietf.org/wg/oauth/charter/ From nobody Tue Dec 15 14:22:13 2015 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECB81B2BEF; Tue, 15 Dec 2015 14:22:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151215222209.24751.37768.idtracker@ietfa.amsl.com> Date: Tue, 15 Dec 2015 14:22:09 -0800 Archived-At: Cc: oauth@ietf.org, draft-ietf-oauth-proof-of-possession@ietf.org, oauth-chairs@ietf.org Subject: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-proof-of-possession-09: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 22:22:09 -0000 Barry Leiba has entered the following ballot position for draft-ietf-oauth-proof-of-possession-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The Abstract and Introduction both say something like this: This specification defines how a JSON Web Token (JWT) [JWT] can declare that the presenter of the JWT possesses a key and that the recipient can cryptographically confirm that the presenter possesses that key. The JWT doesn't declare that the presenter possesses the key; it declares that the presenter *must* possess the key... yes? Shouldn't this say that?: NEW This specification defines how a JSON Web Token (JWT) [JWT] can declare that the presenter of the JWT must possess a key and how the recipient can cryptographically confirm that the presenter possesses that key. END (Also notice change from "that" to "how".) This specification defines how to communicate key confirmation key information in JWTs. "key confirmation key information" seems odd and hard to follow. I think "key information used in key confirmation" is a better way to say it. But perhaps the sentence as a whole could be better phrased. Does something like this work?: NEW This specification defines how to imbed into the JWT the key information that is used in key confirmation. END -- Section 2 -- Minor, very unimportant point: There's no reason to put, for example, "(JWT)", when the citation "[JWT]" immediately follows it. I suggest just using the citation to provide the abbreviation, and eliminating "(JWT)", "(JWK)", and "(JWE)". But very unimportant; do, or don't, and no need to respond to this item. -- Section 3 -- The issuer of a JWT declares that the presenter possesses a particular key and that the recipient can cryptographically confirm proof-of-possession of the key by the presenter by including a "cnf" (confirmation) claim in the JWT whose value is a JSON object. I was convinced that this wasn't right until I read it for about the eighth time. It sounds like the recipient includes the "cnf" claim in the JWT, when it's actually the issuer. That happens when long sentences have too many qualifiers strung together. How about this?: NEW By including a "cnf" (confirmation) claim in a JWT, the issuer of the JWT declares that the presenter possesses a particular key, and that the recipient can cryptographically confirm that the presenter has proof-of-possession of that key. The value in the cnf claim is a JSON object, and members in that object identify the proof-of-possession key. END -- Section 3.5 -- The protocol used to acquire the resource MUST provide integrity protection; an HTTP GET request to retrieve the JWK Set MUST use Transport Layer Security (TLS) [RFC5246]; and the identity of the server MUST be validated, as per Section 6 of RFC 6125 [RFC6125]. Little editorial punctuational nonsense: I would make the first semicolon a colon instead (or perhaps a period), and I would then make the second semicolon a comma. -- Section 4 -- In the last paragraph, can you provide a reference for "audience restriction"? -- Section 6 -- Can we get this fixed in all the OAuth and JOSE documents? It's getting old having to make the same comment for every document: We should not be trying to set up IANA processes in our IANA Considerations. The fourth and sixth paragraphs aren't appropriate here: IANA coordinates and tracks registration requests, and all requests should go to IANA. IANA will contact the DEs, not the other way around. The authors have seen this comment from me before.... From nobody Wed Dec 16 14:17:18 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDB51A900A for ; Wed, 16 Dec 2015 14:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wc3HowF7ridi for ; Wed, 16 Dec 2015 14:17:15 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4B11A8FD4 for ; Wed, 16 Dec 2015 14:17:15 -0800 (PST) Received: by mail-ig0-x229.google.com with SMTP id ph11so164311209igc.1 for ; Wed, 16 Dec 2015 14:17:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UZElj0VKUd/wnjV60THN95k/b1v6adwJ74S3Pe05YhY=; b=ORoTVrFIgGV7GjYOJYE1fZVwU6E6hV0q8NkoGNV60JXZNqXgukpMFT2WbWBsfXhu29 4ktpqZFPgigfinFvvOonB6KTS9zID2UCFEoCCD8v6K91b61ySMVtjEeAEOicrpH9F14M /74iLCjxsjvNsXSd4Tz+R8IDwRRVoF4n1WWBILPxfGQZh7VC4GX+W9A4J9oOlG40+SlJ 5V8P2wan/UsqgQDi9gbaoEiaiXR/9aPU9YxfYx1NqFp7IgGkgikM4Qch5fpgC8n3JQxn R7h/KADd9o10thWMYoHoxPBaYm4bnWSVh4KGjaDmechGwqhyxU8wFvjc2xq5JLJ33dV7 ahjQ== MIME-Version: 1.0 X-Received: by 10.107.33.203 with SMTP id h194mr39838824ioh.108.1450304234600; Wed, 16 Dec 2015 14:17:14 -0800 (PST) Received: by 10.107.34.75 with HTTP; Wed, 16 Dec 2015 14:17:14 -0800 (PST) In-Reply-To: References: Date: Wed, 16 Dec 2015 17:17:14 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Mike Jones Content-Type: multipart/alternative; boundary=001a114072e0b83e6d05270b447b Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Token Exchange: An STS for the REST of Us X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 22:17:17 -0000 --001a114072e0b83e6d05270b447b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mike, In section 2.2.1 Successful Response, the text states that refresh_token is NOT RECOMMENDED, but it does not explain the reason behind this. Can you please elaborate on this point and explain the rational behind this choice? Another question is around the impact of the new token on the subject token. Does a successful response mean that the Client can no longer use the subject token? Regards, Rifaat On Mon, Dec 14, 2015 at 3:05 AM, Mike Jones wrote: > I=E2=80=99m happy to report that a substantially revised OAuth 2.0 Token = Exchange > draft has been published that enables a broad range of use cases, while > still remaining as simple as possible. This draft unifies the approaches > taken in the previous working group draft and draft-campbell-oauth-sts, > incorporating working group input from the in-person discussions in Pragu= e > and mailing list discussions. Thanks to all for your interest in and > contributions to OAuth Token Exchange! Brian Campbell deserves special > recognition for doing much of the editing heavy lifting for this draft. > > > > The core functionality remains token type independent. That said, new > claims are also defined to enable representation of delegation actors in > JSON Web Tokens (JWTs). Equivalent claims could be defined for other tok= en > types by other specifications. > > > > See the Document History section for a summary of the changes made. > Please check it out! > > > > The specification is available at: > > =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-0= 3 > > > > An HTML-formatted version is also available at: > > =C2=B7 > http://self-issued.info/docs/draft-ietf-oauth-token-exchange-03.html > > > > -- Mike > > > > P.S. This note was also posted at http://self-issued.info/?p=3D1509 and = as > @selfissued . > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a114072e0b83e6d05270b447b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mike,

In section 2.2.1 Successful Re= sponse, the text states that refresh_token is NOT RECOMMENDED, but it does = not explain the reason behind this.
Can you please elaborate on t= his point and explain the rational behind this choice?

=
Another question is around the impact of the new token on the subject = token.=C2=A0
Does a successful response mean that the Client can = no longer use the subject token?

Regards,
=C2=A0Rifaat



On Mon, Dec 14, 2015 at 3:05 AM, Mik= e Jones <Michael.Jones@microsoft.com> wrote:

I=E2=80=99m happy to report that a substantially rev= ised OAuth 2.0 Token Exchange draft has been published that enables a broad= range of use cases, while still remaining as simple as possible.=C2=A0 Thi= s draft unifies the approaches taken in the previous working group draft and draft-campbell-oauth-sts, incorporating working gr= oup input from the in-person discussions in Prague and mailing list discuss= ions.=C2=A0 Thanks to all for your interest in and contributions to OAuth T= oken Exchange!=C2=A0 Brian Campbell deserves special recognition for doing much of the editing heavy lifting for this d= raft.

=C2=A0

The core functionality remains token type independen= t.=C2=A0 That said, new claims are also defined to enable representation of= delegation actors in JSON Web Tokens (JWTs).=C2=A0 Equivalent claims could= be defined for other token types by other specifications.

=C2=A0

See the Document History section for a summary of th= e changes made.=C2=A0 Please check it out!

=C2=A0

The specification is available at:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/dra= ft-ietf-oauth-token-exchange-03

=C2=A0

An HTML-formatted version is also available at:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://self-issued.info= /docs/draft-ietf-oauth-token-exchange-03.html

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike<= u>

=C2=A0

P.S.=C2=A0 This note was also posted at http://self-issued.info/?p=3D1509 and as @selfissued.


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--001a114072e0b83e6d05270b447b-- From nobody Wed Dec 16 15:54:24 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA421A9130; Wed, 16 Dec 2015 15:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhgMMin-7OfE; Wed, 16 Dec 2015 15:54:20 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0770.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::770]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFA441A9126; Wed, 16 Dec 2015 15:54:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=E0laRVOCryWbvP0nx53y/OVJCEPX82K2oT4YajW2uqU=; b=gDJ4GJpXWzGot9TceEjox5VwyqcfHoY9oJvb5PzWrfZODi3hdk3P+AZ1pZZws/iE7tVBs9eXnFCLLNQECO+pKBSxPQzzXSybXoWSWarHgh0t8MbefAWOM9ozn2QzLXDYr674I0CcLPF+S0h6w/EweNwF7+Y69VcqdzPGNERPcD8= Received: from BL2PR03MB433.namprd03.prod.outlook.com (10.141.92.19) by BL2PR03MB434.namprd03.prod.outlook.com (10.141.92.22) with Microsoft SMTP Server (TLS) id 15.1.355.16; Wed, 16 Dec 2015 23:53:58 +0000 Received: from BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) by BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) with mapi id 15.01.0355.012; Wed, 16 Dec 2015 23:53:57 +0000 From: Mike Jones To: Barry Leiba , The IESG Thread-Topic: Barry Leiba's No Objection on draft-ietf-oauth-proof-of-possession-09: (with COMMENT) Thread-Index: AQHRN4cLmDK7wJJIJEK+vtr4cZl3Np7OPS6A Date: Wed, 16 Dec 2015 23:53:57 +0000 Message-ID: References: <20151215222209.24751.37768.idtracker@ietfa.amsl.com> In-Reply-To: <20151215222209.24751.37768.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [188.92.133.18] x-microsoft-exchange-diagnostics: 1; BL2PR03MB434; 5:eB5+1Ntj5xwDoQ9X8d/cagS/5Dvv6uVbIYpxXaOtLQnipOpz5/wy71WQkCLepvho0HpQwaMMY5wvCwK9adqbqtPqoKJwL58o2mCUakPLMHp5wVtUvt/JkDDdgArgfZHNhNewJ/QvY6UFXPGKz30XqA==; 24:Y55jtQCuU8HiPwsiitZ3N1Ro6VGMVkzt4mhARHOvUE1r3+DWD7RJOveNkLOSV3Nl+yI2VliUoqIO135w5XFcFqLnJfDSDdq5xppG1Q+FmZg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB434; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BL2PR03MB434; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB434; x-forefront-prvs: 0792DBEAD0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(52044002)(43784003)(189002)(377454003)(199003)(13464003)(97736004)(86362001)(81156007)(15975445007)(99286002)(2900100001)(5004730100002)(50986999)(5001770100001)(2950100001)(54356999)(76176999)(106356001)(77096005)(87936001)(106116001)(86612001)(74316001)(230783001)(105586002)(33656002)(10090500001)(40100003)(10400500002)(10290500002)(122556002)(8990500004)(101416001)(92566002)(5005710100001)(66066001)(5003600100002)(6116002)(102836003)(5002640100001)(586003)(5001960100002)(3846002)(189998001)(1220700001)(19580405001)(19580395003)(5008740100001)(1096002)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB434; H:BL2PR03MB433.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2015 23:53:57.8055 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB434 Archived-At: Cc: "oauth@ietf.org" , "draft-ietf-oauth-proof-of-possession@ietf.org" , "oauth-chairs@ietf.org" Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-proof-of-possession-09: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 23:54:22 -0000 SGkgQmFycnksDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXcuICBQbGVhc2Ugc2VlIG15IHJlc3Bv bnNlcyBpbmxpbmUgYmVsb3cuLi4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBCYXJyeSBMZWliYSBbbWFpbHRvOmJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnXQ0KPiBTZW50 OiBUdWVzZGF5LCBEZWNlbWJlciAxNSwgMjAxNSAxMToyMiBQTQ0KPiBUbzogVGhlIElFU0cgPGll c2dAaWV0Zi5vcmc+DQo+IENjOiBkcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Npb25A aWV0Zi5vcmc7IG9hdXRoLWNoYWlyc0BpZXRmLm9yZzsNCj4ga2VwZW5nLmxrcEBhbGliYWJhLWlu Yy5jb207IG9hdXRoQGlldGYub3JnDQo+IFN1YmplY3Q6IEJhcnJ5IExlaWJhJ3MgTm8gT2JqZWN0 aW9uIG9uIGRyYWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0NCj4gMDk6ICh3aXRo IENPTU1FTlQpDQo+IA0KPiBCYXJyeSBMZWliYSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJh bGxvdCBwb3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1vYXV0aC1wcm9vZi1vZi1wb3NzZXNzaW9u LTA5OiBObyBPYmplY3Rpb24NCj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhl IHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbA0KPiBhZGRyZXNzZXMg aW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBp bnRyb2R1Y3RvcnkNCj4gcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiBQbGVhc2UgcmVm ZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJp YS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09N TUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVy IGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Npb24vDQo+ IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiANCj4gVGhlIEFic3RyYWN0IGFuZCBJbnRyb2R1Y3Rpb24gYm90aCBzYXkgc29tZXRoaW5nIGxp a2UgdGhpczoNCj4gDQo+ICAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGhvdyBhIEpTT04g V2ViIFRva2VuIChKV1QpIFtKV1RdIGNhbg0KPiAgICBkZWNsYXJlIHRoYXQgdGhlIHByZXNlbnRl ciBvZiB0aGUgSldUIHBvc3Nlc3NlcyBhIGtleSBhbmQgdGhhdCB0aGUNCj4gICAgcmVjaXBpZW50 IGNhbiBjcnlwdG9ncmFwaGljYWxseSBjb25maXJtIHRoYXQgdGhlIHByZXNlbnRlciBwb3NzZXNz ZXMNCj4gICAgdGhhdCBrZXkuDQo+IA0KPiBUaGUgSldUIGRvZXNuJ3QgZGVjbGFyZSB0aGF0IHRo ZSBwcmVzZW50ZXIgcG9zc2Vzc2VzIHRoZSBrZXk7IGl0IGRlY2xhcmVzDQo+IHRoYXQgdGhlIHBy ZXNlbnRlciAqbXVzdCogcG9zc2VzcyB0aGUga2V5Li4uIHllcz8gIFNob3VsZG4ndCB0aGlzIHNh eQ0KPiB0aGF0PzoNCj4gDQo+IE5FVw0KPiAgICBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBo b3cgYSBKU09OIFdlYiBUb2tlbiAoSldUKSBbSldUXSBjYW4NCj4gICAgZGVjbGFyZSB0aGF0IHRo ZSBwcmVzZW50ZXIgb2YgdGhlIEpXVCBtdXN0IHBvc3Nlc3MgYSBrZXkgYW5kIGhvdw0KPiAgICB0 aGUgcmVjaXBpZW50IGNhbiBjcnlwdG9ncmFwaGljYWxseSBjb25maXJtIHRoYXQgdGhlIHByZXNl bnRlcg0KPiAgICBwb3NzZXNzZXMgdGhhdCBrZXkuDQo+IEVORA0KPiANCj4gKEFsc28gbm90aWNl IGNoYW5nZSBmcm9tICJ0aGF0IiB0byAiaG93Ii4pDQoNCkhvdyBhYm91dCB0aGlzIHZlcnNpb24g aW5zdGVhZD8NCg0KIlRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGhvdyB0byBkZWNsYXJlIGlu IGEgSlNPTiBXZWIgVG9rZW4gKEpXVCkgdGhhdCB0aGUgcHJlc2VudGVyIG9mIHRoZSBKV1QgcG9z c2Vzc2VzIGEgcGFydGljdWxhciBwcm9vZi1vZi1wb3NzZXNzaW9uIGtleSBhbmQgdGhhdCB0aGUg cmVjaXBpZW50IGNhbiBjcnlwdG9ncmFwaGljYWxseSBjb25maXJtIHByb29mLW9mLXBvc3Nlc3Np b24gb2YgdGhlIGtleSBieSB0aGUgcHJlc2VudGVyLiBCZWluZyBhYmxlIHRvIHByb3ZlIHBvc3Nl c3Npb24gb2YgYSBrZXkgaXMgYWxzbyBzb21ldGltZXMgZGVzY3JpYmVkIGFzIHRoZSBwcmVzZW50 ZXIgYmVpbmcgYSBob2xkZXItb2Yta2V5LiINCg0KVGhlIHByb3Bvc2VkICJtdXN0IHBvc3Nlc3Mi IHdvcmRpbmcgZm9yIHNvbWUgcmVhc29uIHNvdW5kcyBhd2t3YXJkIHRvIG15IGVhciBhbmQgdGhl ICJtdXN0IiBpcyByZWR1bmRhbnQsIHNpbmNlIGZvciB0aGUgc3RhdGVtZW50ICJ0aGUgcmVjaXBp ZW50IGNhbiBjcnlwdG9ncmFwaGljYWxseSBjb25maXJtIHByb29mLW9mLXBvc3Nlc3Npb24gb2Yg dGhlIGtleSIgdG8gYmUgdHJ1ZSwgdGhlIHByZXNlbnRlciBtdXN0IHBvc3Nlc3MgdGhlIGtleS4N Cg0KQSBjaGFuZ2UgZnJvbSAidGhhdCIgdG8gImhvdyIgd291bGQgaW1wbHkgc29tZXRoaW5nIHRo YXQgaXNuJ3QgdHJ1ZSAtIHRoYXQgdGhpcyBzcGVjIHNheXMgKmhvdyogdGhlIHJlY2lwaWVudCBj b25mb3JtcyBwcm9vZiBvZiBwb3NzZXNzaW9uLiAgVGhlIGNvbmZvcm1hdGlvbiBwcm90b2NvbCBt ZXNzYWdlKHMpIHVzZWQgZm9yIHBhcnRpY3VsYXIgYXBwbGljYXRpb25zIGFyZSBleHBsaWNpdGx5 IG91dCBvZiBzY29wZSBmb3IgdGhpcyBzcGVjaWZpY2F0aW9uLiAgSWYgd2Ugc2FpZCAiaG93Iiwg cmVhZGVycyB3b3VsZCBsYXRlciBmZWVsIGNoZWF0ZWQuIFRodXMsIEkgaGF2ZW4ndCBtYWRlIHRo aXMgY2hhbmdlLg0KDQo+ICAgIFRoaXMNCj4gICAgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGhvdyB0 byBjb21tdW5pY2F0ZSBrZXkgY29uZmlybWF0aW9uIGtleQ0KPiAgICBpbmZvcm1hdGlvbiBpbiBK V1RzLg0KPiANCj4gImtleSBjb25maXJtYXRpb24ga2V5IGluZm9ybWF0aW9uIiBzZWVtcyBvZGQg YW5kIGhhcmQgdG8gZm9sbG93LiAgSSB0aGluaw0KPiAia2V5IGluZm9ybWF0aW9uIHVzZWQgaW4g a2V5IGNvbmZpcm1hdGlvbiIgaXMgYSBiZXR0ZXIgd2F5IHRvIHNheSBpdC4NCj4gQnV0IHBlcmhh cHMgdGhlIHNlbnRlbmNlIGFzIGEgd2hvbGUgY291bGQgYmUgYmV0dGVyIHBocmFzZWQuICBEb2Vz DQo+IHNvbWV0aGluZyBsaWtlIHRoaXMgd29yaz86DQo+IA0KPiBORVcNCj4gICAgVGhpcyBzcGVj aWZpY2F0aW9uIGRlZmluZXMgaG93IHRvIGltYmVkIGludG8gdGhlIEpXVCB0aGUga2V5DQo+ICAg IGluZm9ybWF0aW9uIHRoYXQgaXMgdXNlZCBpbiBrZXkgY29uZmlybWF0aW9uLg0KPiBFTkQNCg0K SSBhZ3JlZSB0aGF0IHRoZSBzZW50ZW5jZSB5b3UgY2l0ZWQgaXMgYXdrd2FyZC4gIEhvdyBhYm91 dCB0aGlzIGluc3RlYWQ/DQoNCiJUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBob3cgdG8gY29t bXVuaWNhdGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHByb29mLW9mLXBvc3Nlc3Npb24ga2V5IHVz aW5nIGEgY2xhaW0gaW4gYSBKV1QuIg0KDQo+IC0tIFNlY3Rpb24gMiAtLQ0KPiBNaW5vciwgdmVy eSB1bmltcG9ydGFudCBwb2ludDogVGhlcmUncyBubyByZWFzb24gdG8gcHV0LCBmb3IgZXhhbXBs ZSwNCj4gIihKV1QpIiwgd2hlbiB0aGUgY2l0YXRpb24gIltKV1RdIiBpbW1lZGlhdGVseSBmb2xs b3dzIGl0LiAgSSBzdWdnZXN0IGp1c3QNCj4gdXNpbmcgdGhlIGNpdGF0aW9uIHRvIHByb3ZpZGUg dGhlIGFiYnJldmlhdGlvbiwgYW5kIGVsaW1pbmF0aW5nICIoSldUKSIsDQo+ICIoSldLKSIsIGFu ZCAiKEpXRSkiLiAgQnV0IHZlcnkgdW5pbXBvcnRhbnQ7IGRvLCBvciBkb24ndCwgYW5kIG5vIG5l ZWQgdG8NCj4gcmVzcG9uZCB0byB0aGlzIGl0ZW0uDQoNCk9LDQoNCj4gLS0gU2VjdGlvbiAzIC0t DQo+IA0KPiAgICBUaGUgaXNzdWVyIG9mIGEgSldUIGRlY2xhcmVzIHRoYXQgdGhlIHByZXNlbnRl ciBwb3NzZXNzZXMgYQ0KPiAgICBwYXJ0aWN1bGFyIGtleSBhbmQgdGhhdCB0aGUgcmVjaXBpZW50 IGNhbiBjcnlwdG9ncmFwaGljYWxseSBjb25maXJtDQo+ICAgIHByb29mLW9mLXBvc3Nlc3Npb24g b2YgdGhlIGtleSBieSB0aGUgcHJlc2VudGVyIGJ5IGluY2x1ZGluZyBhICJjbmYiDQo+ICAgIChj b25maXJtYXRpb24pIGNsYWltIGluIHRoZSBKV1Qgd2hvc2UgdmFsdWUgaXMgYSBKU09OIG9iamVj dC4NCj4gDQo+IEkgd2FzIGNvbnZpbmNlZCB0aGF0IHRoaXMgd2Fzbid0IHJpZ2h0IHVudGlsIEkg cmVhZCBpdCBmb3IgYWJvdXQgdGhlIGVpZ2h0aCB0aW1lLg0KPiBJdCBzb3VuZHMgbGlrZSB0aGUg cmVjaXBpZW50IGluY2x1ZGVzIHRoZSAiY25mIiBjbGFpbSBpbiB0aGUgSldULCB3aGVuIGl0J3MN Cj4gYWN0dWFsbHkgdGhlIGlzc3Vlci4gIFRoYXQgaGFwcGVucyB3aGVuIGxvbmcgc2VudGVuY2Vz IGhhdmUgdG9vIG1hbnkNCj4gcXVhbGlmaWVycyBzdHJ1bmcgdG9nZXRoZXIuICBIb3cgYWJvdXQg dGhpcz86DQo+IA0KPiBORVcNCj4gICAgQnkgaW5jbHVkaW5nIGEgImNuZiIgKGNvbmZpcm1hdGlv bikgY2xhaW0gaW4gYSBKV1QsIHRoZSBpc3N1ZXINCj4gICAgb2YgdGhlIEpXVCBkZWNsYXJlcyB0 aGF0IHRoZSBwcmVzZW50ZXIgcG9zc2Vzc2VzIGEgcGFydGljdWxhciBrZXksDQo+ICAgIGFuZCB0 aGF0IHRoZSByZWNpcGllbnQgY2FuIGNyeXB0b2dyYXBoaWNhbGx5IGNvbmZpcm0gdGhhdCB0aGUN Cj4gICAgcHJlc2VudGVyIGhhcyBwcm9vZi1vZi1wb3NzZXNzaW9uIG9mIHRoYXQga2V5LiAgVGhl IHZhbHVlIGluIHRoZQ0KPiAgICBjbmYgY2xhaW0gaXMgYSBKU09OIG9iamVjdCwgYW5kIG1lbWJl cnMgaW4gdGhhdCBvYmplY3QgaWRlbnRpZnkNCj4gICAgdGhlIHByb29mLW9mLXBvc3Nlc3Npb24g a2V5Lg0KPiBFTkQNCg0KU291bmRzIGdvb2QNCg0KPiAtLSBTZWN0aW9uIDMuNSAtLQ0KPiANCj4g ICAgVGhlIHByb3RvY29sIHVzZWQgdG8gYWNxdWlyZSB0aGUgcmVzb3VyY2UgTVVTVCBwcm92aWRl IGludGVncml0eQ0KPiAgICBwcm90ZWN0aW9uOyBhbiBIVFRQIEdFVCByZXF1ZXN0IHRvIHJldHJp ZXZlIHRoZSBKV0sgU2V0IE1VU1QgdXNlDQo+ICAgIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAo VExTKSBbUkZDNTI0Nl07IGFuZCB0aGUgaWRlbnRpdHkgb2YgdGhlDQo+ICAgIHNlcnZlciBNVVNU IGJlIHZhbGlkYXRlZCwgYXMgcGVyIFNlY3Rpb24gNiBvZiBSRkMgNjEyNSBbUkZDNjEyNV0uDQo+ IA0KPiBMaXR0bGUgZWRpdG9yaWFsIHB1bmN0dWF0aW9uYWwgbm9uc2Vuc2U6IEkgd291bGQgbWFr ZSB0aGUgZmlyc3Qgc2VtaWNvbG9uIGENCj4gY29sb24gaW5zdGVhZCAob3IgcGVyaGFwcyBhIHBl cmlvZCksIGFuZCBJIHdvdWxkIHRoZW4gbWFrZSB0aGUgc2Vjb25kDQo+IHNlbWljb2xvbiBhIGNv bW1hLg0KDQpJIGFncmVlIHRoaXMgaXMgY3VycmVudGx5IG92ZXJseSBmdXNzeS4gIEknbGwgY2hh bmdlIHRoZSBmaXJzdCBzZW1pY29sb24gdG8gYSBwZXJpb2QgYW5kIHJlbW92ZSB0aGUgc2Vjb25k Lg0KDQo+IC0tIFNlY3Rpb24gNCAtLQ0KPiBJbiB0aGUgbGFzdCBwYXJhZ3JhcGgsIGNhbiB5b3Ug cHJvdmlkZSBhIHJlZmVyZW5jZSBmb3IgImF1ZGllbmNlIHJlc3RyaWN0aW9uIj8NCg0KU3VyZSAt IEknbGwgY2l0ZSBKV1QgNC4xLjMgLSB0aGUgImF1ZCIgY2xhaW0uDQoNCj4gLS0gU2VjdGlvbiA2 IC0tDQo+IENhbiB3ZSBnZXQgdGhpcyBmaXhlZCBpbiBhbGwgdGhlIE9BdXRoIGFuZCBKT1NFIGRv Y3VtZW50cz8gIEl0J3MgZ2V0dGluZyBvbGQNCj4gaGF2aW5nIHRvIG1ha2UgdGhlIHNhbWUgY29t bWVudCBmb3IgZXZlcnkgZG9jdW1lbnQ6ICBXZSBzaG91bGQgbm90IGJlDQo+IHRyeWluZyB0byBz ZXQgdXAgSUFOQSBwcm9jZXNzZXMgaW4gb3VyIElBTkEgQ29uc2lkZXJhdGlvbnMuICBUaGUgZm91 cnRoIGFuZA0KPiBzaXh0aCBwYXJhZ3JhcGhzIGFyZW4ndCBhcHByb3ByaWF0ZSBoZXJlOiBJQU5B IGNvb3JkaW5hdGVzIGFuZCB0cmFja3MNCj4gcmVnaXN0cmF0aW9uIHJlcXVlc3RzLCBhbmQgYWxs IHJlcXVlc3RzIHNob3VsZCBnbyB0byBJQU5BLiAgSUFOQSB3aWxsIGNvbnRhY3QNCj4gdGhlIERF cywgbm90IHRoZSBvdGhlciB3YXkgYXJvdW5kLiAgVGhlIGF1dGhvcnMgaGF2ZSBzZWVuIHRoaXMg Y29tbWVudA0KPiBmcm9tIG1lIGJlZm9yZS4uLi4NCg0KRmFpciBlbm91Z2guICBJJ2xsIGRlbGV0 ZSB0aGVzZSBwYXJhZ3JhcGhzLCBtb3ZpbmcgdGhlIDIxLWRheSB0aW1lIHBlcmlvZCBzZW50ZW5j ZSB0byBhbm90aGVyIGxvY2F0aW9uLiANCg0KSSdsbCBub3cgd29yayBvbiBhcHBseWluZyB0aGVz ZSByZXNvbHV0aW9ucyB0byB0aGUgc3BlY2lmaWNhdGlvbiBhbmQgdGhlbiB3aWxsIHJlcHVibGlz aC4NCg0KCQkJCVRoYW5rcyBhZ2FpbiENCgkJCQktLSBNaWtlDQoNCg== From nobody Wed Dec 16 19:02:48 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE751A8839; Wed, 16 Dec 2015 19:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPhmEZz7lxC3; Wed, 16 Dec 2015 19:02:42 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672F41A1B6A; Wed, 16 Dec 2015 19:02:42 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id a189so38757006vkh.2; Wed, 16 Dec 2015 19:02:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ahZIfhs4wCdKxByitx+RLR+kDClYhkNTTYKnlyuE2y8=; b=cj1+1i9OzYXp538IHc3Od62jkeTyY6D2a3yWHGmsMvLq0FgqpQNLNLizGDo8GdddWo dTG/EyGHKKZTm6eh+UqnYVnkduIFCrfkedOWZ0L+71MciZAlzHb8CSpqzEUe9uQng6Ta r+Beg9eikyV88oxmP51ip/UZQSo2/w+fpkzyBddstaGN0dW5GCwi6SH1QBr9hcAHC/Qa kdBEGcElb0WZpfJmsdkgFSq6tlfyiVkkTcdwvcEanQA5W26clFPtKFHLol24IsN4ppxW kpLsVx/88C0gYziVqE0t1/lZlryqEk06RtDXW+2+38FaArOXSubC6+rZMf8pZe6Pasib 6h1A== MIME-Version: 1.0 X-Received: by 10.31.107.138 with SMTP id k10mr16231304vki.27.1450321361582; Wed, 16 Dec 2015 19:02:41 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.31.182.211 with HTTP; Wed, 16 Dec 2015 19:02:41 -0800 (PST) In-Reply-To: References: <20151215222209.24751.37768.idtracker@ietfa.amsl.com> Date: Wed, 16 Dec 2015 22:02:41 -0500 X-Google-Sender-Auth: C7k6GlrZLP0RtWJV2gNJ7adRUSQ Message-ID: From: Barry Leiba To: Mike Jones Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "oauth-chairs@ietf.org" , "draft-ietf-oauth-proof-of-possession@ietf.org" , The IESG , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-proof-of-possession-09: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 03:02:43 -0000 > Thanks for your review. Please see my responses inline below... And thanks for your responses. All OK, including the alternatives you gave to my suggestions. Thanks, as always, for addressing my comments. Barry From nobody Wed Dec 16 19:11:41 2015 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3561A8839; Wed, 16 Dec 2015 19:11:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151217031137.9696.44578.idtracker@ietfa.amsl.com> Date: Wed, 16 Dec 2015 19:11:37 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-proof-of-possession-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 03:11:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) Authors : Michael B. Jones John Bradley Hannes Tschofenig Filename : draft-ietf-oauth-proof-of-possession-10.txt Pages : 18 Date : 2015-12-16 Abstract: This specification defines how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and that the recipient can cryptographically confirm proof-of-possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-proof-of-possession-10 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 16 19:13:25 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE9A1A92F4; Wed, 16 Dec 2015 19:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ige6iJWKfCQ; Wed, 16 Dec 2015 19:13:22 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0747.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::747]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FF1C1AC3BA; Wed, 16 Dec 2015 19:13:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fSJG1IFpt8dhX3MMZdbUY7x4DiIsvZPfS6JF3tBC9hA=; b=kLrsr/RDW0LZwZuOPu4CJJ0oOf1EYKcfFuKQfA9e/tZdFD+EIcHIKfaUrp6E9LRXLxaBpxfcVqXcCl0Jd6XpiXEDJJDz4ynoIpk4jRS0QSTrF1T9ueKSmfXXFAeol8vF/NbY/bOCGuyoDioJsSgo7KeguH5QUs0c4hD0vZJ/dGM= Received: from BL2PR03MB433.namprd03.prod.outlook.com (10.141.92.19) by BL2PR03MB436.namprd03.prod.outlook.com (10.141.92.26) with Microsoft SMTP Server (TLS) id 15.1.355.16; Thu, 17 Dec 2015 03:13:05 +0000 Received: from BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) by BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) with mapi id 15.01.0355.012; Thu, 17 Dec 2015 03:13:05 +0000 From: Mike Jones To: Barry Leiba Thread-Topic: Barry Leiba's No Objection on draft-ietf-oauth-proof-of-possession-09: (with COMMENT) Thread-Index: AQHRN4cLmDK7wJJIJEK+vtr4cZl3Np7OPS6AgABCjYCAAAKRUA== Date: Thu, 17 Dec 2015 03:13:05 +0000 Message-ID: References: <20151215222209.24751.37768.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [188.92.133.18] x-microsoft-exchange-diagnostics: 1; BL2PR03MB436; 5:WRzesb1PM/y8jAqgM6tRBd2/Y8e1XE+Q5e5zDRm09byzPqh3Lu0QITj5acceSue5h+ndF30rX7t0QLkVQKnDDFt3BFLmajks+c29R3ZJRR7UEh8acr6Yf5zqoJIqS0fxvz5hfqNVmR5Hn6X4Xplq8Q==; 24:zMEscnUBKcRbCJPBqTXTnA04pCZ3QO4rtnemlizMWOw5YNDOpxl/Ye6/Defo9xeksz87rIy2bYMQVh3NmKS4XzfksIJRzNOmLwxORc2p+IE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB436; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BL2PR03MB436; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB436; x-forefront-prvs: 07935ACF08 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(43784003)(189002)(164054003)(199003)(5002640100001)(76176999)(5001960100002)(50986999)(97736004)(54356999)(110136002)(189998001)(11100500001)(33656002)(66066001)(81156007)(101416001)(230783001)(76576001)(2950100001)(74316001)(105586002)(1096002)(5008740100001)(102836003)(3846002)(6116002)(586003)(122556002)(40100003)(19580405001)(19580395003)(87936001)(77096005)(92566002)(106116001)(106356001)(2900100001)(5005710100001)(10400500002)(86362001)(5004730100002)(10290500002)(8990500004)(10090500001)(1220700001)(86612001)(5003600100002)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB436; H:BL2PR03MB433.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2015 03:13:05.2009 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB436 Archived-At: Cc: "oauth-chairs@ietf.org" , "draft-ietf-oauth-proof-of-possession@ietf.org" , The IESG , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-proof-of-possession-09: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 03:13:24 -0000 RHJhZnQgLTEwIGlzIHBvc3RlZCwgd2hpY2ggYWRkcmVzc2VzIHlvdXIgYmFsbG90IGNvbW1lbnRz Lg0KDQoJCQkJVGhhbmtzIGFnYWluLA0KCQkJCS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IGJhcnJ5bGVpYmFAZ21haWwuY29tIFttYWlsdG86YmFycnlsZWliYUBn bWFpbC5jb21dIE9uIEJlaGFsZiBPZiBCYXJyeSBMZWliYQ0KU2VudDogVGh1cnNkYXksIERlY2Vt YmVyIDE3LCAyMDE1IDQ6MDMgQU0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20+DQpDYzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+OyBrZXBlbmcubGtwQGFsaWJh YmEtaW5jLmNvbTsgb2F1dGhAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9z c2Vzc2lvbkBpZXRmLm9yZzsgb2F1dGgtY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogQmFy cnkgTGVpYmEncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1vYXV0aC1wcm9vZi1vZi1wb3Nz ZXNzaW9uLTA5OiAod2l0aCBDT01NRU5UKQ0KDQo+IFRoYW5rcyBmb3IgeW91ciByZXZpZXcuICBQ bGVhc2Ugc2VlIG15IHJlc3BvbnNlcyBpbmxpbmUgYmVsb3cuLi4NCg0KQW5kIHRoYW5rcyBmb3Ig eW91ciByZXNwb25zZXMuICBBbGwgT0ssIGluY2x1ZGluZyB0aGUgYWx0ZXJuYXRpdmVzIHlvdSBn YXZlIHRvIG15IHN1Z2dlc3Rpb25zLiAgVGhhbmtzLCBhcyBhbHdheXMsIGZvciBhZGRyZXNzaW5n IG15IGNvbW1lbnRzLg0KDQpCYXJyeQ0K From nobody Thu Dec 17 02:24:32 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6D11A8870 for ; Thu, 17 Dec 2015 02:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POa_foy9HIVf for ; Thu, 17 Dec 2015 02:24:27 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0142.outbound.protection.outlook.com [65.55.169.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8DCD1A884F for ; Thu, 17 Dec 2015 02:24:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=M55E/E41CtKB3UqOrULrdOdYH0jJ9sob3c6/isFqucw=; b=NuxxfxlgnRqrbmED8iWdSpJQh3hn0yIT+VfICzPNbs0j4PfRqq4/SKKbmxceJbzo7UZMqqn4MBBqYgfHdFuBoq7heVijFVBuIkJPJ4r7vTovE9k4NqNcD8wxFYfSx+D/y2LKtqDkLr+PGU6XKeTsTYbd/wXp6rtLDqRR8Rz8cRA= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.355.16; Thu, 17 Dec 2015 10:24:23 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0355.012; Thu, 17 Dec 2015 10:24:23 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Proof-of-Possession Key Semantics for JWTs spec for IESG telechat Thread-Index: AdE4qH2ybTWWL/OHQK6DCATQvnHeFA== Date: Thu, 17 Dec 2015 10:24:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [93.216.71.75] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:FIxxyW/rZknm+NomwBHCqvw+9j0ATRCY3uHQDiT89kmWuKIuEIlhW5qmfYzPqyApHc0yvgyK9UGBPtwE40i2zD2sZQIcTbQY5/BUxv+XGiPu3rTZ3CH0MsSSiUHHWB1ELUxWlmmYPf3jDegsxp4AvA==; 24:CmeC+TV9j+k/VlhQrMYjkvUP04UfalT6BKHSs3YxE7XJGGaSubWr6L62TfgrVIUu7u8xPZB2fFBGnl/1JfN5+7ba5Hbs+ePGPdKb5AGuxGo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 07935ACF08 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(189002)(199003)(19617315012)(101416001)(87936001)(19300405004)(16236675004)(19580395003)(229853001)(2351001)(86362001)(86612001)(66066001)(19625215002)(33656002)(2501003)(5008740100001)(40100003)(92566002)(122556002)(15975445007)(77096005)(1730700002)(2900100001)(586003)(54356999)(1096002)(102836003)(3846002)(6116002)(790700001)(1220700001)(50986999)(5002640100001)(110136002)(5001960100002)(97736004)(81156007)(5003600100002)(11100500001)(106356001)(189998001)(105586002)(10090500001)(5004730100002)(99286002)(230783001)(5005710100001)(8990500004)(10290500002)(10400500002)(76576001)(74316001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4420BBFCA9872C50E9DC417F5E00BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2015 10:24:23.5301 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: Barry Leiba Subject: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec for IESG telechat X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 10:24:31 -0000 --_000_BY2PR03MB4420BBFCA9872C50E9DC417F5E00BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Proof-of-Possession Key Semantics for JWTs draft -10 was published for cons= ideration on the IESG telechat later today. All changes were editorial and= addressed ballot comments by Barry Leiba. The specification is available at: * http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-10 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-1= 0.html -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1514 and as= @selfissued. --_000_BY2PR03MB4420BBFCA9872C50E9DC417F5E00BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Proof-of-Possession Key Semantics for JWTs draft -10= was published for consideration on the IESG telechat later today.  Al= l changes were editorial and addressed ballot comments by Barry Leiba.

 

The specification is available at:

·       http://tools.ietf.org/html/draft-ietf-oa= uth-proof-of-possession-10

 

An HTML-formatted version is also available at:=

·       http://self-issued.info/docs/draf= t-ietf-oauth-proof-of-possession-10.html

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           -- Mike

 

P.S.  This note was also posted at http://self-issued.info/?p=3D= 1514 and as @selfissued.

 

--_000_BY2PR03MB4420BBFCA9872C50E9DC417F5E00BY2PR03MB442namprd_-- From nobody Thu Dec 17 03:45:21 2015 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3B81B2B92; Thu, 17 Dec 2015 03:45:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151217114518.32317.77951.idtracker@ietfa.amsl.com> Date: Thu, 17 Dec 2015 03:45:18 -0800 Archived-At: Cc: oauth@ietf.org, draft-ietf-oauth-proof-of-possession@ietf.org, oauth-chairs@ietf.org Subject: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-proof-of-possession-10: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 11:45:19 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-oauth-proof-of-possession-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Figure 1 and the discussion thereof: you talk all the time here about "a symmetric key" so I think you ought add a footnote like bit of text that says something like "note that there ought be more than one key involved here, derived from the key exchanged at (0) via a KDF." I kinda wish that all that had been covered in one document but I guess that's part of the PoP arch doc, which is for later. - 3.1 says "outside the scope of this specification": just wondering - does that phrase occur in all OAuth RFCs? (only kidding, honest:-) - section 4, para 2: replay can also be avoided if a sub-key is derived from a shared secret that is specific to the instance of the PoP demonstration. - section 6: DE guidance - I think we ought tell the DEs that the specification of a new thing needs to explicitly describe the security properties of using the new thing. - I didn't see a response to the secdir review [1] but that was maybe sent to the wrong places. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06266.html From nobody Thu Dec 17 06:00:28 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8151B2C02; Thu, 17 Dec 2015 06:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoNjAlcJMLvP; Thu, 17 Dec 2015 06:00:23 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82601B2B40; Thu, 17 Dec 2015 06:00:22 -0800 (PST) Received: from [80.67.16.130] (helo=webmail.df.eu) by smtprelay03.ispgateway.de with esmtpa (Exim 4.84) (envelope-from ) id 1a9Z55-0006U6-40; Thu, 17 Dec 2015 14:58:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 17 Dec 2015 15:00:19 +0100 From: torsten@lodderstedt.net To: RFC Errata System In-Reply-To: <20151208150508.1B4581832BB@rfc-editor.org> References: <20151208150508.1B4581832BB@rfc-editor.org> Message-ID: <1736001e4c00fa68e6f3b232ec59c4de@lodderstedt.net> X-Sender: torsten@lodderstedt.net User-Agent: Roundcube Webmail X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: david.gladstone@nib.co.nz, phil.hunt@yahoo.com, Kathleen.Moriarty@emc.com, iesg@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] [Errata Held for Document Update] RFC6819 (4267) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 14:00:27 -0000 Hi all, the report is correct. Please consider it an errata to RFC 6819. kind regards, Torsten. Am 08.12.2015 16:05, schrieb RFC Errata System: > The following errata report has been held for document update > for RFC6819, "OAuth 2.0 Threat Model and Security Considerations". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6819&eid=4267 > > -------------------------------------- > Status: Held for Document Update > Type: Editorial > > Reported by: David Gladstone > Date Reported: 2015-02-09 > Held by: Kathleen Moriarty (IESG) > > Section: 4.4.1.11 > > Original Text > ------------- > If an authorization server includes a nontrivial amount of entropy > > Corrected Text > -------------- > If an authorization server includes a trivial amount of entropy > > Notes > ----- > The threat being described outlines a scenario where too little > entropy is involved; countermeasures include using non-trivial amounts > of entropy. > > -------------------------------------- > RFC6819 (draft-ietf-oauth-v2-threatmodel-08) > -------------------------------------- > Title : OAuth 2.0 Threat Model and Security > Considerations > Publication Date : January 2013 > Author(s) : T. Lodderstedt, Ed., M. McGloin, P. Hunt > Category : INFORMATIONAL > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG From nobody Thu Dec 17 06:03:25 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2641B2D0B; Thu, 17 Dec 2015 06:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjLfRYJPIgsv; Thu, 17 Dec 2015 06:03:20 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63B581B2DEC; Thu, 17 Dec 2015 06:03:19 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tBHE3DWt030882 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Dec 2015 14:03:14 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tBHE3DsE011726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Dec 2015 14:03:13 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tBHE3COJ030456; Thu, 17 Dec 2015 14:03:12 GMT Received: from [192.168.2.104] (/93.216.71.75) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Dec 2015 06:03:11 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13C75) In-Reply-To: <1736001e4c00fa68e6f3b232ec59c4de@lodderstedt.net> Date: Thu, 17 Dec 2015 15:02:47 +0100 Content-Transfer-Encoding: 7bit Message-Id: <7F7D33B0-2245-4B21-AE0C-819E9B3BB6EB@oracle.com> References: <20151208150508.1B4581832BB@rfc-editor.org> <1736001e4c00fa68e6f3b232ec59c4de@lodderstedt.net> To: torsten@lodderstedt.net X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: david.gladstone@nib.co.nz, iesg@ietf.org, Kathleen.Moriarty@emc.com, oauth@ietf.org, RFC Errata System Subject: Re: [OAUTH-WG] [Errata Held for Document Update] RFC6819 (4267) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 14:03:24 -0000 +1 Phil > On Dec 17, 2015, at 15:00, torsten@lodderstedt.net wrote: > > Hi all, > > the report is correct. Please consider it an errata to RFC 6819. > > kind regards, > Torsten. > > Am 08.12.2015 16:05, schrieb RFC Errata System: >> The following errata report has been held for document update >> for RFC6819, "OAuth 2.0 Threat Model and Security Considerations". >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=6819&eid=4267 >> -------------------------------------- >> Status: Held for Document Update >> Type: Editorial >> Reported by: David Gladstone >> Date Reported: 2015-02-09 >> Held by: Kathleen Moriarty (IESG) >> Section: 4.4.1.11 >> Original Text >> ------------- >> If an authorization server includes a nontrivial amount of entropy >> Corrected Text >> -------------- >> If an authorization server includes a trivial amount of entropy >> Notes >> ----- >> The threat being described outlines a scenario where too little >> entropy is involved; countermeasures include using non-trivial amounts >> of entropy. >> -------------------------------------- >> RFC6819 (draft-ietf-oauth-v2-threatmodel-08) >> -------------------------------------- >> Title : OAuth 2.0 Threat Model and Security Considerations >> Publication Date : January 2013 >> Author(s) : T. Lodderstedt, Ed., M. McGloin, P. Hunt >> Category : INFORMATIONAL >> Source : Web Authorization Protocol >> Area : Security >> Stream : IETF >> Verifying Party : IESG From nobody Thu Dec 17 06:03:44 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796AB1B2D0B for ; Thu, 17 Dec 2015 06:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIiZDdBOsIPl for ; Thu, 17 Dec 2015 06:03:40 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7342D1B2DED for ; Thu, 17 Dec 2015 06:03:40 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id p187so22848658wmp.0 for ; Thu, 17 Dec 2015 06:03:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ag6USYpbzAr3yMREsO59ZTntE/shrl+dzCPKoIyc8Ng=; b=TPnpvEIcHe7PZR+Le+1Hec5GegsojkJb5HM5FQ5Dt88YufVL7PPeagTHlSBvpXv2sn LXAGn3+YF7NGyIqjEzA5uEf/XaNujeILYdTa3ZxFFQYzJkIyGrStBXRTg9wd5nbj5LLd 68RnbCB+/pHlL5mxstroPA4FP6u0UNTcZMuqH/SL6n4VnpH7Z85x0Y6RI32vPzfIiEPv dJwCBqPn2XM7Xgk8xhdr+BYLPGKPMY9d/LJW6YCOlk6kDqDE3q0M1Lg6reUSOKS3m9tb 30oRG+G6DDPDUU496scpEYIfGhNjUvI7Ec2M3o0g2puT1vVnVcqIxJstUic3WUAYkK2i T/pg== MIME-Version: 1.0 X-Received: by 10.28.218.17 with SMTP id r17mr4408039wmg.90.1450361018938; Thu, 17 Dec 2015 06:03:38 -0800 (PST) Received: by 10.28.52.130 with HTTP; Thu, 17 Dec 2015 06:03:38 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Dec 2015 09:03:38 -0500 Message-ID: From: Kathleen Moriarty To: Mike Jones Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Barry Leiba , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec for IESG telechat X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 14:03:42 -0000 Hi Mike, Thanks for getting these comments addressed prior to the call today! Barry, thanks for your detailed review! Kathleen On Thu, Dec 17, 2015 at 5:24 AM, Mike Jones w= rote: > Proof-of-Possession Key Semantics for JWTs draft -10 was published for > consideration on the IESG telechat later today. All changes were editori= al > and addressed ballot comments by Barry Leiba. > > > > The specification is available at: > > =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possess= ion-10 > > > > An HTML-formatted version is also available at: > > =C2=B7 > http://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-10.html > > > > -- Mike > > > > P.S. This note was also posted at http://self-issued.info/?p=3D1514 and = as > @selfissued. > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Best regards, Kathleen From nobody Thu Dec 17 07:02:21 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13751B2E85; Thu, 17 Dec 2015 07:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSJ4HUaoepGM; Thu, 17 Dec 2015 07:02:11 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0112.outbound.protection.outlook.com [207.46.100.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16DE1B2E78; Thu, 17 Dec 2015 07:02:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yuDKgmfV3AgWIYTLAnHFx2rWR6Ze45V6ncduXO1Pq9w=; b=gJQ4fyCxmazMyDAFf1qrfiyi5FGhIcq4SXl5DQlgUfwKTrZ+etFGh5uc8aMy6Um5sVGBPjVDou2b/W/fGy7G7zaICEsh59UgGjHWM0xv4PnFIWYhPoVi3fhzVtb9diQfyNOMmD6+Ns52ONpWA5WGBDoTI4LcTCHQyG+e1ATNu5M= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.355.16; Thu, 17 Dec 2015 15:02:10 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0355.012; Thu, 17 Dec 2015 15:02:10 +0000 From: Mike Jones To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's No Objection on draft-ietf-oauth-proof-of-possession-10: (with COMMENT) Thread-Index: AQHROMBqUlUD/WQSuESV2w18wq8t6Z7PRCQg Date: Thu, 17 Dec 2015 15:02:10 +0000 Message-ID: References: <20151217114518.32317.77951.idtracker@ietfa.amsl.com> In-Reply-To: <20151217114518.32317.77951.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [93.216.71.75] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:YGrr2U/6o2+R+1dFnvG9jcLnhlB+M4obi6WnFl28VCsfA9dOatFcQqfdyk4YVnu3glHVy6cg2Wpvx7PPlsuJZjOr4t29J8gkwjFm2D4sWBWYb4KcqJIE6VWetU+drVJPZBpW5al/Y15zIOdMLJEy6A==; 24:jpuPNv6yrxhbxfAuIBfQrvr7SUfcHNjLO/vY04Q0A/hCV4agZlUg9gGl/4ro2BgzEluA1lHbJzfXxD6cV3/ROHolg7m8c7M4NtWoAAHffOM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 07935ACF08 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(52604005)(13464003)(52044002)(377454003)(97736004)(5001770100001)(5001960100002)(5002640100001)(189998001)(5003600100002)(11100500001)(106356001)(81156007)(6116002)(3846002)(54356999)(1096002)(102836003)(50986999)(76176999)(1220700001)(106116001)(76576001)(74316001)(5004730100002)(230783001)(10090500001)(105586002)(99286002)(10400500002)(8990500004)(10290500002)(5005710100001)(86612001)(66066001)(86362001)(87936001)(101416001)(19580405001)(19580395003)(15975445007)(77096005)(586003)(2900100001)(5008740100001)(33656002)(2950100001)(122556002)(92566002)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2015 15:02:10.1208 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Cc: "oauth@ietf.org" , "draft-ietf-oauth-proof-of-possession@ietf.org" , "oauth-chairs@ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-proof-of-possession-10: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 15:02:15 -0000 VGhhbmtzIGZvciB5b3VyIHJldmlldywgU3RlcGhlbi4gIFJlcGxpZXMgaW5saW5lIGJlbG93Li4u DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU3RlcGhlbiBGYXJyZWxs IFttYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZV0NCj4gU2VudDogVGh1cnNkYXksIERl Y2VtYmVyIDE3LCAyMDE1IDEyOjQ1IFBNDQo+IFRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4N Cj4gQ2M6IGRyYWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbkBpZXRmLm9yZzsgb2F1 dGgtY2hhaXJzQGlldGYub3JnOw0KPiBrZXBlbmcubGtwQGFsaWJhYmEtaW5jLmNvbTsgb2F1dGhA aWV0Zi5vcmcNCj4gU3ViamVjdDogU3RlcGhlbiBGYXJyZWxsJ3MgTm8gT2JqZWN0aW9uIG9uIGRy YWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtDQo+IHBvc3Nlc3Npb24tMTA6ICh3aXRoIENPTU1FTlQp DQo+IA0KPiBTdGVwaGVuIEZhcnJlbGwgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3Qg cG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0xMDog Tm8gT2JqZWN0aW9uDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJq ZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1 ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9k dWN0b3J5DQo+IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRv IGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRt bA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQg cG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxs b3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1wcm9vZi1vZi1wb3NzZXNzaW9uLw0KPiANCj4g DQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+ IA0KPiAtIEZpZ3VyZSAxIGFuZCB0aGUgZGlzY3Vzc2lvbiB0aGVyZW9mOiB5b3UgdGFsayBhbGwg dGhlIHRpbWUgaGVyZSBhYm91dCAiYQ0KPiBzeW1tZXRyaWMga2V5IiBzbyBJIHRoaW5rIHlvdSBv dWdodCBhZGQgYSBmb290bm90ZSBsaWtlIGJpdCBvZiB0ZXh0IHRoYXQgc2F5cw0KPiBzb21ldGhp bmcgbGlrZSAibm90ZSB0aGF0IHRoZXJlIG91Z2h0IGJlIG1vcmUgdGhhbiBvbmUga2V5IGludm9s dmVkIGhlcmUsDQo+IGRlcml2ZWQgZnJvbSB0aGUga2V5IGV4Y2hhbmdlZCBhdCAoMCkgdmlhIGEg S0RGLiIgSSBraW5kYSB3aXNoIHRoYXQgYWxsIHRoYXQNCj4gaGFkIGJlZW4gY292ZXJlZCBpbiBv bmUgZG9jdW1lbnQgYnV0IEkgZ3Vlc3MgdGhhdCdzIHBhcnQgb2YgdGhlIFBvUCBhcmNoDQo+IGRv Yywgd2hpY2ggaXMgZm9yIGxhdGVyLg0KDQpTb3VuZHMgZ29vZA0KDQo+IC0gMy4xIHNheXMgIm91 dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiI6IGp1c3Qgd29uZGVyaW5nIC0g ZG9lcyB0aGF0DQo+IHBocmFzZSBvY2N1ciBpbiBhbGwgT0F1dGggUkZDcz8gKG9ubHkga2lkZGlu ZywgaG9uZXN0Oi0pDQoNCjstKQ0KDQo+IC0gc2VjdGlvbiA0LCBwYXJhIDI6IHJlcGxheSBjYW4g YWxzbyBiZSBhdm9pZGVkIGlmIGEgc3ViLWtleSBpcyBkZXJpdmVkIGZyb20gYQ0KPiBzaGFyZWQg c2VjcmV0IHRoYXQgaXMgc3BlY2lmaWMgdG8gdGhlIGluc3RhbmNlIG9mIHRoZSBQb1AgZGVtb25z dHJhdGlvbi4NCg0KR29vZCAtIHdpbGwgYWRkDQoNCj4gLSBzZWN0aW9uIDY6IERFIGd1aWRhbmNl IC0gSSB0aGluayB3ZSBvdWdodCB0ZWxsIHRoZSBERXMgdGhhdCB0aGUgc3BlY2lmaWNhdGlvbg0K PiBvZiBhIG5ldyB0aGluZyBuZWVkcyB0byBleHBsaWNpdGx5IGRlc2NyaWJlIHRoZSBzZWN1cml0 eSBwcm9wZXJ0aWVzIG9mIHVzaW5nIHRoZQ0KPiBuZXcgdGhpbmcuDQoNCk9LDQoNCj4gLSBJIGRp ZG4ndCBzZWUgYSByZXNwb25zZSB0byB0aGUgc2VjZGlyIHJldmlldyBbMV0gYnV0IHRoYXQgd2Fz IG1heWJlIHNlbnQgdG8NCj4gdGhlIHdyb25nIHBsYWNlcy4NCj4gDQo+ICAgIFsxXSBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NlY2Rpci9jdXJyZW50L21zZzA2MjY2Lmh0 bWwNCg0KVGhhbmtzIGZvciBwb2ludGluZyB0aGlzIG91dC4gIE15IG1haWwgc3lzdGVtIGhhZCBo ZWxwZnVsbHkgc29ydGVkIHRoaXMgbm90ZSBpbiB0byBteSBDbHV0dGVyIGZvbGRlci4gOi0vICBJ J2xsIHNlbmQgYSByZXBseSBzaG9ydGx5Lg0KDQoJCQkJLS0gTWlrZQ0K From nobody Thu Dec 17 07:24:57 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898B71B2EB7 for ; Thu, 17 Dec 2015 07:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0dKw-N4gVKl for ; Thu, 17 Dec 2015 07:24:54 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826A71B2EA0 for ; Thu, 17 Dec 2015 07:24:54 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id q126so58323052iof.2 for ; Thu, 17 Dec 2015 07:24:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+jwot8ockiSGHrSFLZZFzGRcUGBce8YE19lMDYbFk4I=; b=gp9BudrksAF0+JPrdEN/02vIuOV9JWMWyvbimi1EqEQFVTrDyROIfNY/0ihpOft0l8 GuajXuthXd26Lb5AZnglxqJ9W/UKHppX5vq+WLyO8LObozuSG+DvnOhesq8n3bk4Bp1W O2uBDDrGztLTC1X+NlHv+bVnhFf1J+QyJtLG0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+jwot8ockiSGHrSFLZZFzGRcUGBce8YE19lMDYbFk4I=; b=Cxqxll+pjYcyp/OUNo8WyaDqu2rz17cHNDxKTfiEtlh7y18wK0vtpMX5yMbf8LWblG NNedkDNMOGu6VxQn4HLKzMv8xuiWFvJEEWP42rpc23MvjS4p2XhVlDV3hEt11dG1xejo i1Mx/ZnxmY9LYO3AIqKheEKRMRFsxz3huymBlgXpsTWkqzLYHhQrXRvn87D31wZAggbl dqneqEoAQMPWV8ddzREDkQv4XjPo+kwbhLp/ZT1GpZVGuFB16IEmcoaTGPB+z3d7dFq5 OvJuUW0roN97gt41M221VLlU5fQkk59/7Kg/RIP0BlvkBBM+E0hDqycCzk0AuAFmgz0J ctEw== X-Gm-Message-State: ALoCoQkivbOjB09HbsbMYJiYwSWlzER+eMLAIFhnlb8UiRpIKmhj2FjhjnNZXZVx20yuY4kabLPoLPu0Oft7YcPkntFLNt+qZDCqH5UwCb99BekD39EdHDg= X-Received: by 10.107.158.213 with SMTP id h204mr58152154ioe.129.1450365893880; Thu, 17 Dec 2015 07:24:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.23.133 with HTTP; Thu, 17 Dec 2015 07:24:24 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Thu, 17 Dec 2015 16:24:24 +0100 Message-ID: To: Rifaat Shekh-Yusef Content-Type: multipart/alternative; boundary=001a114075c2e64a040527199f76 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Token Exchange: An STS for the REST of Us X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 15:24:56 -0000 --001a114075c2e64a040527199f76 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fair questions Rifaat, Typically a token exchange is done to exchange a temporary credential (the token the client sends in) for a different temporary credential (the issued token) that can be used in some other context. A refresh token would be an additional credential issued and one that probably isn't so temporary (the lifetime of refresh tokens depends on the deployment/implementation but are often unlimited or relatively long), which sort of undermines the typical token exchange model of swapping temporary credentials. Does that explain it any more? I can add some text along those lines into the next draft. In general the act of doing the exchange has no impact on the validity of the subject token (or actor token). I suppose that particular kinds of token could have one-time-use semantics or something like that, which would mean the doing the exchange makes it no longer usable. But that would be a specific detail of the particular kind of token. On Wed, Dec 16, 2015 at 11:17 PM, Rifaat Shekh-Yusef wrote: > Hi Mike, > > In section 2.2.1 Successful Response, the text states that refresh_token > is NOT RECOMMENDED, but it does not explain the reason behind this. > Can you please elaborate on this point and explain the rational behind > this choice? > > Another question is around the impact of the new token on the subject > token. > Does a successful response mean that the Client can no longer use the > subject token? > > Regards, > Rifaat > > > > On Mon, Dec 14, 2015 at 3:05 AM, Mike Jones > wrote: > >> I=E2=80=99m happy to report that a substantially revised OAuth 2.0 Token= Exchange >> draft has been published that enables a broad range of use cases, while >> still remaining as simple as possible. This draft unifies the approache= s >> taken in the previous working group draft and draft-campbell-oauth-sts, >> incorporating working group input from the in-person discussions in Prag= ue >> and mailing list discussions. Thanks to all for your interest in and >> contributions to OAuth Token Exchange! Brian Campbell deserves special >> recognition for doing much of the editing heavy lifting for this draft. >> >> >> >> The core functionality remains token type independent. That said, new >> claims are also defined to enable representation of delegation actors in >> JSON Web Tokens (JWTs). Equivalent claims could be defined for other to= ken >> types by other specifications. >> >> >> >> See the Document History section for a summary of the changes made. >> Please check it out! >> >> >> >> The specification is available at: >> >> =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-= 03 >> >> >> >> An HTML-formatted version is also available at: >> >> =C2=B7 >> http://self-issued.info/docs/draft-ietf-oauth-token-exchange-03.html >> >> >> >> -- Mike >> >> >> >> P.S. This note was also posted at http://self-issued.info/?p=3D1509 and >> as @selfissued . >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a114075c2e64a040527199f76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fair questions Rifaat,

Typically a= token exchange is done to exchange a temporary credential (the token the c= lient sends in) for a different temporary credential (the issued token) tha= t can be used in some other context. A refresh token would be an additional= credential issued and one that probably isn't so temporary (the lifeti= me of refresh tokens depends on the deployment/implementation but are often= unlimited or relatively long), which sort of undermines the typical token = exchange model of swapping temporary credentials. Does that explain it any = more? I can add some text along those lines into the next draft.

In general the act of doing the exchange has no impact on the validity = of the subject token (or actor token). I suppose that particular kinds of t= oken could have one-time-use semantics or something like that, which would = mean the doing the exchange makes it no longer usable. But that would be a = specific detail of the particular kind of token.=C2=A0



On Wed, Dec 16= , 2015 at 11:17 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com><= /span> wrote:
Hi Mike,
In section 2.2.1 Successful Response, the text states tha= t refresh_token is NOT RECOMMENDED, but it does not explain the reason behi= nd this.
Can you please elaborate on this point and explain the r= ational behind this choice?

Another question is ar= ound the impact of the new token on the subject token.=C2=A0
Does= a successful response mean that the Client can no longer use the subject t= oken?

Regards,
=C2=A0Rifaat


On Mon, Dec 14, 2015 at 3:05 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I=E2=80=99m happy to report that a substantially rev= ised OAuth 2.0 Token Exchange draft has been published that enables a broad= range of use cases, while still remaining as simple as possible.=C2=A0 Thi= s draft unifies the approaches taken in the previous working group draft and draft-campbell-oauth-sts, incorporating working gr= oup input from the in-person discussions in Prague and mailing list discuss= ions.=C2=A0 Thanks to all for your interest in and contributions to OAuth T= oken Exchange!=C2=A0 Brian Campbell deserves special recognition for doing much of the editing heavy lifting for this d= raft.

=C2=A0

The core functionality remains token type independen= t.=C2=A0 That said, new claims are also defined to enable representation of= delegation actors in JSON Web Tokens (JWTs).=C2=A0 Equivalent claims could= be defined for other token types by other specifications.

=C2=A0

See the Document History section for a summary of th= e changes made.=C2=A0 Please check it out!

=C2=A0

The specification is available at:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/dra= ft-ietf-oauth-token-exchange-03

=C2=A0

An HTML-formatted version is also available at:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://self-issued.info= /docs/draft-ietf-oauth-token-exchange-03.html

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike<= u>

=C2=A0

P.S.=C2=A0 This note was also posted at http://self-issued.info/?p=3D1509 and as @selfissued.


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--001a114075c2e64a040527199f76-- From nobody Thu Dec 17 07:59:42 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E0A1B2EF8 for ; Thu, 17 Dec 2015 07:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Wo4zOrb0WiE for ; Thu, 17 Dec 2015 07:59:38 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0604F1B2EFB for ; Thu, 17 Dec 2015 07:59:37 -0800 (PST) Received: from [192.168.10.142] ([93.216.71.75]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MVMgI-1ZhUMI0VfK-00Ym4B for ; Thu, 17 Dec 2015 16:59:36 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <5672DBE7.30101@gmx.net> Date: Thu, 17 Dec 2015 16:59:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="E7dEg9cBi8EV3vUqMQ87m9CWqVBh9SS22" X-Provags-ID: V03:K0:N+gWDCCKcHoeKlhYwMGc05P1jIX88lSU1sqc3a1/a1/fU/Sodxn ay4B2Uva/LNbiENwPLvE+LJMF7Gp6+9up/tcZ45XhzcHz/G/VKsoCzL3x+/wMyTuvvUfeyy f3WramIz0EJPffXKBCGXKPJpLoMUYX0u+MLcvU+Yoag0DESpdK/jwPUdW29Ufr7kOwlwhvz DS4tbw1z7WqaXfkuWQwVQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:1PyIoq0e+jU=:6GnsHxjyW3COl2GsgL5HTS d52A+ZXz2T66CKx61Tqt82QXl5XrIbNNQXi8cfm6ng15McsC1g/jqFNUaKTFl3utL3Nk23rhs KEWvHVHUYhQzVFupHJZIFyY46O+KVemERJNv2220GBfcqPlN6KESnHeRVjBpoJQ8V7jXVtxHQ tXaxxiIdpXYVcDfL4cQULU5HMCl8XMTfqjKLAtqyFgzoe5hsUF8Rm98b3kC4JWmTe0tV2SGpR rW5HeDCcXXDrO8wPBtxOJCbrXuTlHEReRovcgtsjDP9Z8SU1qW6w+ZXX8Xy29SiekrZe3U1Ah g5wtnqJ1a1+beU1q+2aFcxme7j+dtftyNEY8+HRTB7i+zcTqvlMphSFqbt7YMoj5gs1Ng1GPU YuoOpWZEwoxtj2fmnaZwJdDOi+JwFTNBy3uATP/ZOK0ZTr+rV+ejU9UA9t6KNpWX+as3ijOUR oe6q/cbJbvoK9sIJjVixYBRUgEuf2kL9fYtQptq/3Bh4tanEWVqqLqX7culz2drRMgHLWsXTY jsiPBpWYtN3suJhO8H+/juRZuiAunEnrBxZfEL/3vsS9r+1o1LMVOqtaqgZNYLJZHrotgBll7 GMM9NLh6V0vHp0npedichINSAKDULhauRUuyxrjEaw5+QGEvCx38QpqdqAhVX30nz5A1I2+iN y1kiCuu16/7ASku63uf9Za5doRlk3+ykhVCiQSGN9neqnuHR3mlj5nWvfU3pEHrtyenDidFG1 3vAAauQLVfRJ2l+LOPzundlgCoqfmuH5R1MKkhNOTdLRlzGTqaXbMcq2NpM= Archived-At: Subject: [OAUTH-WG] OAuth Recharting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 15:59:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --E7dEg9cBi8EV3vUqMQ87m9CWqVBh9SS22 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, at the last IETF meeting in Yokohama we had a rechartering discussion and below is proposed text for the new charter. Please take a look at it and tell me whether it appropriately covers the discussions from our last meeting. --------------- Charter Text The Web Authorization (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account and without having the user share his or her photo-sharing sites' long-term credential with the printing site. The OAuth 2.0 protocol suite already includes * a procedure for enabling a client to register with an authorization server, * a protocol for obtaining authorization tokens from an authorization server with the resource owner's consent, and * protocols for presenting these authorization tokens to protected resources for access to a resource. This protocol suite has been enhanced with functionality for interworking with legacy identity infrastructure (e.g., SAML), token revocation, token exchange, dynamic client registration, token introspection, a standardized token format with the JSON Web Token, and specifications that mitigate security attacks, such as Proof Key for Code Exchange. The ongoing standardization efforts within the OAuth working group focus on increasing interoperability of OAuth deployments and to improve security. More specifically, the working group is defining proof of possession tokens, developing a discovery mechanism, providing guidance for the use of OAuth with native apps, re-introducing the device flow used by devices with limited user interfaces, additional security enhancements for clients communicating with multiple service providers, definition of claims used with JSON Web Tokens, techniques to mitigate open redirector attacks, as well as guidance on encoding state information. For feedback and discussion about our specifications please subscribe to our public mailing list. For security related bug reports that relate to our specifications please contact <>. If the reported bug report turns out to be implementation-specific we will attempt to forward it to the appropriate developers. --------------- Ciao Hannes --E7dEg9cBi8EV3vUqMQ87m9CWqVBh9SS22 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWctvoAAoJEGhJURNOOiAtcjQH/1makwT7gvakftYK4x3fwoMO 2eZn8z32wCSWzmHT5nMrEi+6nFACO2vBpkfSx7AG7xPr0YQXZcEyALkLSsaaaJ3g ZX3SLyy1iC8C/AHZ8I26YZ9ZweGMagDjg7WC5SYr4DrTOJ61/R5KYQGJlu4p/0nR ykTEhTLizpg+PiGSwRZDJTvzVts+J+gEk26JKfckm8ICJoUY4oxFXQRFOWifVmK/ D6pmEtHlbfaJn2ulv3zMCttbIkMwW9z5m0HRj1W5BvLzMBCKm2polKaA+NTAb96K +nPpE6+E7Ow5L/LplUksn1jMl70cvE0jdgjMIGvkg1hzUNtTOABJqlPla40/tmk= =lCQ+ -----END PGP SIGNATURE----- --E7dEg9cBi8EV3vUqMQ87m9CWqVBh9SS22-- From nobody Thu Dec 17 08:12:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC6F1B2F23 for ; Thu, 17 Dec 2015 08:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxxqu1xiXAjN for ; Thu, 17 Dec 2015 08:12:12 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BE3A1B2F20 for ; Thu, 17 Dec 2015 08:12:11 -0800 (PST) Received: from [192.168.10.142] ([93.216.71.75]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M4GRv-1aQiKy3lbf-00rs7Y for ; Thu, 17 Dec 2015 17:12:09 +0100 To: oauth@ietf.org References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <5672DED4.2070104@gmx.net> Date: Thu, 17 Dec 2015 17:12:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xdOwVMhfqrd8REXcSKTrbc6R26OwlQ7D6" X-Provags-ID: V03:K0:+sYgG8lDmyWqxy0sE286ELNfINaVvWpWN7kiJfVsEsgGLfQE6Q0 7v5u02ylG17OUI93BdwOrXsDg6D1YLd1NnLQ6wAFAOgaZNWleCi1jIEQyQXP1uqqcXvyKR9 sn1lGN3mfzC2IrBGL5qv+MAw8Rz6N1sTJ8ht5DSKohcmmrfylA3XPOZpKsKP5D61XmCtMz7 vWL4vkStd7sJcqJsFErUA== X-UI-Out-Filterresults: notjunk:1;V01:K0:KxnGXJ1S+c4=:eurVKK12uuGXbvtG9r6gWx 2aq6o+MecrWAvk0H2mQdUUyFByp73GjXYkwtaifAMaQgh2SoPEkOxUu83KIJQ/WCgQ+cU932u QCfCx3w+9DpwGbQZHW/mOElOEnaYY1VHLHiqIAyDO2kWgbq23PdduBNfVxsU7mhYnzUyvje9X 9qK4cvZOW+HR7DYJS8FdXVMWxaA947VLlZUIOxpawh09J8kE1SAOw0uVlHnj4p/j5HjhJG6+W IGd7seLwD5j+7jhWMI851L78J86N99jMn/e2W2U+pDAkarDxVUqdvyqfipIL585pTarugfAmj dy3+N544iMUqhDRMY5lyoufvn9wcTS8NpkZRqPff5zT7iV3dDVUvnigeUAWJKU/KK2k3zed9b A+QjfaTlUCOrAyaEHtOcOwLIPApj9F42fY1rZbrNtvUeaMXNbRP2794DRb/IBv5nGZAHJ/nAO bPjrhTk8g77obYiA6KdU9gtxR9xCA8A0smGOA0oaTFGsHeALhxURuiVfn1X928wOmhs8kW9NF XSXWAlVqmOb7WvA1jVbxHRyRybAjltACuOv1IeIwvwCwCSSqWs6Va8iKNtBARgksU8TmwtIi8 D+KRlCKsRAWyZ4VVSX32WLt2SWsCZBeQnW+8JVHYrUz1uKxfQZsb9ttAeV4w7AmWB0G89zS2Q o/npM8ieqKFt4/EWOSVb6Jpaclq0W200mq/FqCiChdHWeOifuv/R6+MqaET1ShMnTZN69plBu uVCQwjhFDmWX+TtgVy+88hIAQsAs2DqZIvgHQBAJlzuzGF9MTQiTeLGrI50= Archived-At: Subject: Re: [OAUTH-WG] implementations of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 16:12:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xdOwVMhfqrd8REXcSKTrbc6R26OwlQ7D6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Samuel and I had been working on a prototype implementation of the PoP tokens for an IoT scenario, which we showed at ARM TechCon. It used the JWT (instead of the CBOR-encoded version of the JWT since we had JOSE code available). Our version used symmetric key cryptography. Roland Hedberg also mentioned to me that one person from his group implemented the PoP token functionality and also the functionality outlined in draft-ietf-oauth-proof-of-possession. Ciao Hannes On 12/14/2015 04:13 AM, Kathleen Moriarty wrote: > Hi, >=20 > Are there any implementations of draft-ietf-oauth-proof-of-possession?= >=20 > Thanks! >=20 --xdOwVMhfqrd8REXcSKTrbc6R26OwlQ7D6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWct7UAAoJEGhJURNOOiAtAoIIAI5FyKDtPhDUyb+lWlMG/901 FtdUPDI1JOvVy7I0s1qmYkePHBegDoYnhAAKaOsnCZ5BrSbbDx01HJWx6TDVYHbS EXbn064bppSh54kto5qdIinUykYKMyGWLlgGyedIu5+vE3WhqHoMZSH9uPyhpVOQ FBphwV1LL7NXTPDJZ0d+GSprU2+/z+3JkMYtYHp4djcKyWk1J1Lon9SoI2V8M1Ld MsDloMVCzi2JzNZvVJ9rZ3fz0IurmNF/kAeFSa8cFNKlI3aRh+CIZvARjKcE52tI Sk4xosS+bvJJRWCnHDlpIFESIoOGHu0MlQwrC3AsX88awQG/8oKJ31piWLdQ2xM= =9Sk2 -----END PGP SIGNATURE----- --xdOwVMhfqrd8REXcSKTrbc6R26OwlQ7D6-- From nobody Thu Dec 17 08:21:12 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F971B2F45 for ; Thu, 17 Dec 2015 08:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tT6xhsl1Rh4w for ; Thu, 17 Dec 2015 08:21:08 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 240DC1B2F27 for ; Thu, 17 Dec 2015 08:21:08 -0800 (PST) Received: by mail-ig0-x22a.google.com with SMTP id mv3so16088638igc.0 for ; Thu, 17 Dec 2015 08:21:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m6zj4b++w1/5WOVHh8eNpGJ1Le6oQYyvzdfAXWOqnd0=; b=QpbpUa+2b3QozeDSdu8Cbt0Fey+HVgWHwA6JmPmEPb/vXAoWaqLk5YXiITEerG7ZRE meyMjuBX8eQYLFcYf2CxX3UWCt3dB00jw0PLoh9R0EF5Cke6NN0jiFQm9D1V5tOMABXv JD5he8RSRXRp48BcZgPbCk3VJ0LqPbgHYqmytudsigTNDvX1UmMtwlAi03A+KXMyvv56 WgX+eJ7ycbo8m04Lgvfin80FMaHfC9BH2gAZVFnmPVAspLxrNK553RH2QwZ7cn0ckFRY my4lgCu4sYpjS1T4q+S0ARi2z2d2g6BO9FrEPp1MkO6dlRbZOMSIxyGJ3gOMpTqu3i1d ZX4w== MIME-Version: 1.0 X-Received: by 10.50.124.102 with SMTP id mh6mr3078120igb.12.1450369267559; Thu, 17 Dec 2015 08:21:07 -0800 (PST) Received: by 10.107.147.6 with HTTP; Thu, 17 Dec 2015 08:21:07 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Dec 2015 11:21:07 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Brian Campbell Content-Type: multipart/alternative; boundary=089e0111c1bafc747305271a689d Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Token Exchange: An STS for the REST of Us X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 16:21:10 -0000 --089e0111c1bafc747305271a689d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Brian, Thanks for your response. Yes, that clarifies it for me. It would be great if you can add some text around these two issues to the next version of the document. Regards, Rifaat On Thu, Dec 17, 2015 at 10:24 AM, Brian Campbell wrote: > Fair questions Rifaat, > > Typically a token exchange is done to exchange a temporary credential (th= e > token the client sends in) for a different temporary credential (the issu= ed > token) that can be used in some other context. A refresh token would be a= n > additional credential issued and one that probably isn't so temporary (th= e > lifetime of refresh tokens depends on the deployment/implementation but a= re > often unlimited or relatively long), which sort of undermines the typical > token exchange model of swapping temporary credentials. Does that explain > it any more? I can add some text along those lines into the next draft. > > In general the act of doing the exchange has no impact on the validity of > the subject token (or actor token). I suppose that particular kinds of > token could have one-time-use semantics or something like that, which wou= ld > mean the doing the exchange makes it no longer usable. But that would be = a > specific detail of the particular kind of token. > > > > On Wed, Dec 16, 2015 at 11:17 PM, Rifaat Shekh-Yusef < > rifaat.ietf@gmail.com> wrote: > >> Hi Mike, >> >> In section 2.2.1 Successful Response, the text states that refresh_token >> is NOT RECOMMENDED, but it does not explain the reason behind this. >> Can you please elaborate on this point and explain the rational behind >> this choice? >> >> Another question is around the impact of the new token on the subject >> token. >> Does a successful response mean that the Client can no longer use the >> subject token? >> >> Regards, >> Rifaat >> >> >> >> On Mon, Dec 14, 2015 at 3:05 AM, Mike Jones >> wrote: >> >>> I=E2=80=99m happy to report that a substantially revised OAuth 2.0 Toke= n >>> Exchange draft has been published that enables a broad range of use cas= es, >>> while still remaining as simple as possible. This draft unifies the >>> approaches taken in the previous working group draft and >>> draft-campbell-oauth-sts, incorporating working group input from the >>> in-person discussions in Prague and mailing list discussions. Thanks t= o >>> all for your interest in and contributions to OAuth Token Exchange! Br= ian >>> Campbell deserves special recognition for doing much of the editing hea= vy >>> lifting for this draft. >>> >>> >>> >>> The core functionality remains token type independent. That said, new >>> claims are also defined to enable representation of delegation actors i= n >>> JSON Web Tokens (JWTs). Equivalent claims could be defined for other t= oken >>> types by other specifications. >>> >>> >>> >>> See the Document History section for a summary of the changes made. >>> Please check it out! >>> >>> >>> >>> The specification is available at: >>> >>> =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-token-exchange= -03 >>> >>> >>> >>> An HTML-formatted version is also available at: >>> >>> =C2=B7 >>> http://self-issued.info/docs/draft-ietf-oauth-token-exchange-03.html >>> >>> >>> >>> -- Mike >>> >>> >>> >>> P.S. This note was also posted at http://self-issued.info/?p=3D1509 an= d >>> as @selfissued . >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --089e0111c1bafc747305271a689d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,

Thanks for your response.

Yes, that clarifies it for me. It would be great if y= ou can add some text around these two issues to the next version of the doc= ument.

Regards,
=C2=A0Rifaat
<= br>

On= Thu, Dec 17, 2015 at 10:24 AM, Brian Campbell <bcampbell@pingide= ntity.com> wrote:
Fair questions Rifaat,

Typically a token e= xchange is done to exchange a temporary credential (the token the client se= nds in) for a different temporary credential (the issued token) that can be= used in some other context. A refresh token would be an additional credent= ial issued and one that probably isn't so temporary (the lifetime of re= fresh tokens depends on the deployment/implementation but are often unlimit= ed or relatively long), which sort of undermines the typical token exchange= model of swapping temporary credentials. Does that explain it any more? I = can add some text along those lines into the next draft.

In g= eneral the act of doing the exchange has no impact on the validity of the s= ubject token (or actor token). I suppose that particular kinds of token cou= ld have one-time-use semantics or something like that, which would mean the= doing the exchange makes it no longer usable. But that would be a specific= detail of the particular kind of token.=C2=A0
<= div>


On Wed, Dec 16, 2015 at 11:17 PM, Rifaat Shekh-Yusef <= ;rifaat.ietf@gma= il.com> wrote:
Hi Mike,

In section 2.2.1 Successful Response, the = text states that refresh_token is NOT RECOMMENDED, but it does not explain = the reason behind this.
Can you please elaborate on this point an= d explain the rational behind this choice?

Another= question is around the impact of the new token on the subject token.=C2=A0=
Does a successful response mean that the Client can no longer us= e the subject token?

Regards,
=C2=A0Rifa= at



=
On Mon, Dec 14, 2015 at 3:05 AM, Mike = Jones <Michael.Jones@microsoft.com> wrote:

I=E2=80=99m happy to report that a substantially rev= ised OAuth 2.0 Token Exchange draft has been published that enables a broad= range of use cases, while still remaining as simple as possible.=C2=A0 Thi= s draft unifies the approaches taken in the previous working group draft and draft-campbell-oauth-sts, incorporating working gr= oup input from the in-person discussions in Prague and mailing list discuss= ions.=C2=A0 Thanks to all for your interest in and contributions to OAuth T= oken Exchange!=C2=A0 Brian Campbell deserves special recognition for doing much of the editing heavy lifting for this d= raft.

=C2=A0

The core functionality remains token type independen= t.=C2=A0 That said, new claims are also defined to enable representation of= delegation actors in JSON Web Tokens (JWTs).=C2=A0 Equivalent claims could= be defined for other token types by other specifications.

=C2=A0

See the Document History section for a summary of th= e changes made.=C2=A0 Please check it out!

=C2=A0

The specification is available at:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/dra= ft-ietf-oauth-token-exchange-03

=C2=A0

An HTML-formatted version is also available at:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://self-issued.info= /docs/draft-ietf-oauth-token-exchange-03.html

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike<= u>

=C2=A0

P.S.=C2=A0 This note was also posted at http://self-issued.info/?p=3D1509 and as @selfissued.


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--089e0111c1bafc747305271a689d-- From nobody Thu Dec 17 15:07:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9071B310D for ; Thu, 17 Dec 2015 15:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZovlS8MuL7x for ; Thu, 17 Dec 2015 15:07:10 -0800 (PST) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967C21B310C for ; Thu, 17 Dec 2015 15:07:10 -0800 (PST) Received: by mail-qg0-x22a.google.com with SMTP id p88so5084811qge.1 for ; Thu, 17 Dec 2015 15:07:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ddjenMi4vHbpW7b9zvDH/A1IlyaaBhhZhHpTLXTGxYw=; b=SHkCnyF7j56R85LzTOIDNnh0gSUV6bpAXoMg6kPQiVb4uXLyya1ltjURHJ3Nt/iVBf 6Mfaj/2Uh2cGgb3kzCCgPFF6gXA3o+ya+XjImQ7ZasefAVmvV0hBlVuZHrijzn3NZfQK RARKcsZi/dffX2O1YKcEICsCzHkU0DV2snMP2Xg+DwA+9YiKhEpB5iDIlEwtvrugU0Ax m/JOarWfJ5DB/ZFyFKugbpX8APbvVXepsaxA0owq0H9FtbzwIg0iqOL6Sgckc9Xdv5hW AC4cAYZAnoU+zHImUQsOBnPplf9oabudiH6HOTRetXw4FFjAIJ3e3a3e1yZrHAu54Dl7 AtsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ddjenMi4vHbpW7b9zvDH/A1IlyaaBhhZhHpTLXTGxYw=; b=ZlBvt4QI902K5AcjDZCvjUpOBbLmZ02xPeTqZYc9hI19T4pQV0Vf528vGk6p4rFzCj JGpfxGg2Kdbg2CDCOdNdk+iEXTXmQU8DO5DozWSw4wr81dXa5DKfF0rua3XGBWIiiahM cLRIYTSWVRizdSMdAe7CTZE1EYMoIIc3gqe5lyRmRB3sHBY3azBj9gz5x34WIxXn0cVG rtMWco+fVmhNlBetfvJlWs8yo1CHRDFN5djT2DHOwn2cLKbz7RnZfk3R9APCTr4lLKO7 bb5bYgXOiWu1shHS0a+WyGuKOe1dSTY2NAtDizZJguMNAROrBUM+UbHZ3gGJrJSmWl+3 eJyg== X-Gm-Message-State: ALoCoQmGZC0WtRiEhz6OMmjqYqqYuFDNSYHJPYbSEj3msRCQoTLuoUjbnnKKZkslpCmOyy1Z4Z34prNoEag8p2ehrukLIBLeSsHUsvn2w9FnlYX/K+VTSLg= X-Received: by 10.140.85.102 with SMTP id m93mr515393qgd.83.1450393629706; Thu, 17 Dec 2015 15:07:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.82.231 with HTTP; Thu, 17 Dec 2015 15:06:50 -0800 (PST) In-Reply-To: <5672DBE7.30101@gmx.net> References: <5672DBE7.30101@gmx.net> From: William Denniss Date: Thu, 17 Dec 2015 15:06:50 -0800 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11c128161598b805272015b0 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Recharting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 23:07:12 -0000 --001a11c128161598b805272015b0 Content-Type: text/plain; charset=UTF-8 Looks good to me Hannes, thanks for putting it together! On Thu, Dec 17, 2015 at 7:59 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi all, > > at the last IETF meeting in Yokohama we had a rechartering discussion > and below is proposed text for the new charter. Please take a look at it > and tell me whether it appropriately covers the discussions from our > last meeting. > > --------------- > > Charter Text > > The Web Authorization (OAuth) protocol allows a user to grant a > third-party Web site or application access to the user's protected > resources, without necessarily revealing their long-term credentials, > or even their identity. For example, a photo-sharing site that > supports OAuth could allow its users to use a third-party printing Web > site to print their private pictures, without allowing the printing > site to gain full control of the user's account and without having the > user share his or her photo-sharing sites' long-term credential with > the printing site. > > The OAuth 2.0 protocol suite already includes > > * a procedure for enabling a client to register with an authorization > server, > * a protocol for obtaining authorization tokens from an authorization > server with the resource owner's consent, and > * protocols for presenting these authorization tokens to protected > resources for access to a resource. > > This protocol suite has been enhanced with functionality for > interworking with legacy identity infrastructure (e.g., SAML), token > revocation, token exchange, dynamic client registration, token > introspection, a standardized token format with the JSON Web Token, and > specifications that mitigate security attacks, such as Proof Key for > Code Exchange. > > The ongoing standardization efforts within the OAuth working group > focus on increasing interoperability of OAuth deployments and to > improve security. More specifically, the working group is defining proof > of possession tokens, developing a discovery mechanism, > providing guidance for the use of OAuth with native apps, re-introducing > the device flow used by devices with limited user interfaces, additional > security enhancements for clients communicating with multiple service > providers, definition of claims used with JSON Web Tokens, techniques to > mitigate open redirector attacks, as well as guidance on encoding state > information. > > For feedback and discussion about our specifications please > subscribe to our public mailing list. > > For security related bug reports that relate to our specifications > please contact <>. If the reported bug > report turns out to be implementation-specific we will > attempt to forward it to the appropriate developers. > > --------------- > > > Ciao > Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a11c128161598b805272015b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Looks good to me Hannes, thanks for putting it together!

On Thu, Dec 1= 7, 2015 at 7:59 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

at the last IETF meeting in Yokohama we had a rechartering discussion
and below is proposed text for the new charter. Please take a look at it and tell me whether it appropriately covers the discussions from our
last meeting.

---------------

Charter Text

The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the<= br> user share his or her photo-sharing sites' long-term credential with the printing site.

The OAuth 2.0 protocol suite already includes

* a procedure for enabling a client to register with an authorization
server,
* a protocol for obtaining authorization tokens from an authorization
server with the resource owner's consent, and
* protocols for presenting these authorization tokens to protected
resources for access to a resource.

This protocol suite has been enhanced with functionality for
interworking with legacy identity infrastructure (e.g., SAML), token
revocation, token exchange, dynamic client registration, token
introspection, a standardized token format with the JSON Web Token, and
specifications that mitigate security attacks, such as Proof Key for
Code Exchange.

The ongoing standardization efforts within the OAuth working group
focus on increasing interoperability of OAuth deployments and to
improve security. More specifically, the working group is defining proof of possession tokens, developing a discovery mechanism,
providing guidance for the use of OAuth with native apps, re-introducing the device flow used by devices with limited user interfaces, additional security enhancements for clients communicating with multiple service
providers, definition of claims used with JSON Web Tokens, techniques to mitigate open redirector attacks, as well as guidance on encoding state
information.

For feedback and discussion about our specifications please
subscribe to our public mailing list.

For security related bug reports that relate to our specifications
please contact <<TBD>>. If the reported bug
report turns out to be implementation-specific we will
attempt to forward it to the appropriate developers.

---------------


Ciao
Hannes


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--001a11c128161598b805272015b0-- From nobody Thu Dec 17 17:00:00 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D821B3191 for ; Thu, 17 Dec 2015 16:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.249 X-Spam-Level: X-Spam-Status: No, score=-0.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWD21pNoBTlr for ; Thu, 17 Dec 2015 16:59:56 -0800 (PST) Received: from out4133-18.mail.aliyun.com (out4133-18.mail.aliyun.com [42.120.133.18]) by ietfa.amsl.com (Postfix) with ESMTP id F1AF01B318D for ; Thu, 17 Dec 2015 16:59:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1450400394; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=qYBdC/MWyd9ydP1+JpzJfQ5sgaRIJlehROMPEax7Umg=; b=m0mlwYplZeJZ10OonU+6vEmarn4ya8ZIsO2KWLYxVwZdaHJoJtGC9aTxYJlvoCJON6dg2m6+A6VKdoJKfv4SO6tosTet/vRn8Yf9+FdtZM2wg9VWoGxM343sjXlVSLrpx1dF1Jqa0EOZM5Mw5S7yTa3gNxMyINeVo4PWXz8Jy5Q= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R931e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03301; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=2; SR=0; TI=SMTPD_----4McmtFq_1450400383; Received: from 30.10.35.214(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.183) by smtp.aliyun-inc.com(127.0.0.1); Fri, 18 Dec 2015 08:59:49 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Fri, 18 Dec 2015 08:59:44 +0800 From: "Kepeng Li" To: Hannes Tschofenig , "oauth@ietf.org" Message-ID: Thread-Topic: [OAUTH-WG] OAuth Recharting References: <5672DBE7.30101@gmx.net> In-Reply-To: <5672DBE7.30101@gmx.net> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] OAuth Recharting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2015 00:59:59 -0000 Hi Hannes, Thanks for putting this together. >and specifications that mitigate security attacks, such as Proof Key for >Code Exchange. I propose to change it to: and specifications that mitigate security attacks, such as Proof Key for Code Exchange, and Sender Constraint JSON Web Token. Sender Constaint JWT is mentioned in PoP architecture document, but it is not=20 specified in detail. That is why we provided a separate draft for that. Thanks, Kind Regards Kepeng =D4=DA 17/12/15 11:59 pm=A3=AC "Hannes Tschofenig" =D0=B4=C8=EB= : >Hi all, > >at the last IETF meeting in Yokohama we had a rechartering discussion >and below is proposed text for the new charter. Please take a look at it >and tell me whether it appropriately covers the discussions from our >last meeting. > >--------------- > >Charter Text > >The Web Authorization (OAuth) protocol allows a user to grant a >third-party Web site or application access to the user's protected >resources, without necessarily revealing their long-term credentials, >or even their identity. For example, a photo-sharing site that >supports OAuth could allow its users to use a third-party printing Web >site to print their private pictures, without allowing the printing >site to gain full control of the user's account and without having the >user share his or her photo-sharing sites' long-term credential with >the printing site. > >The OAuth 2.0 protocol suite already includes > >* a procedure for enabling a client to register with an authorization >server, >* a protocol for obtaining authorization tokens from an authorization >server with the resource owner's consent, and >* protocols for presenting these authorization tokens to protected >resources for access to a resource. > >This protocol suite has been enhanced with functionality for >interworking with legacy identity infrastructure (e.g., SAML), token >revocation, token exchange, dynamic client registration, token >introspection, a standardized token format with the JSON Web Token, and >specifications that mitigate security attacks, such as Proof Key for >Code Exchange. > >The ongoing standardization efforts within the OAuth working group >focus on increasing interoperability of OAuth deployments and to >improve security. More specifically, the working group is defining proof >of possession tokens, developing a discovery mechanism, >providing guidance for the use of OAuth with native apps, re-introducing >the device flow used by devices with limited user interfaces, additional >security enhancements for clients communicating with multiple service >providers, definition of claims used with JSON Web Tokens, techniques to >mitigate open redirector attacks, as well as guidance on encoding state >information. > >For feedback and discussion about our specifications please >subscribe to our public mailing list. > >For security related bug reports that relate to our specifications >please contact <>. If the reported bug >report turns out to be implementation-specific we will >attempt to forward it to the appropriate developers. > >--------------- > > >Ciao >Hannes > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Dec 18 20:13:32 2015 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 180DF1A1B67; Fri, 18 Dec 2015 20:13:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151219041331.28089.34794.idtracker@ietfa.amsl.com> Date: Fri, 18 Dec 2015 20:13:31 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-proof-of-possession-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2015 04:13:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) Authors : Michael B. Jones John Bradley Hannes Tschofenig Filename : draft-ietf-oauth-proof-of-possession-11.txt Pages : 18 Date : 2015-12-18 Abstract: This specification defines how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and that the recipient can cryptographically confirm proof-of-possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-proof-of-possession-11 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 18 20:19:01 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB19C1A1B81 for ; Fri, 18 Dec 2015 20:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzQ_9ZotDJn3 for ; Fri, 18 Dec 2015 20:18:56 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0797.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:797]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765A11A1B7F for ; Fri, 18 Dec 2015 20:18:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/q3AX4kLndROMqdAZfB1KutdEtbBIgOccaTNV2HCjJU=; b=c+X4kg6qWxqpqxtxJpM9SqCvMo9h1XIMH3iGA9EXlyCWGtBUyqpR//9jurFEUItTCqs9/emXTlJozPekeKsNwGTpuyD+AiKMafAedWS5irqbDa9teHifdeuQwLDi7ih2+Yy4GHIlaIlu5wJbdkX4F/Flk7GVXWOmzKN7Y6i7RA8= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.355.16; Sat, 19 Dec 2015 04:18:38 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0355.012; Sat, 19 Dec 2015 04:18:38 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Proof-of-Possession Key Semantics for JWTs spec addressing remaining comments Thread-Index: AdE6CHm8w2dY6rTWSU+ghKOWbgZ10g== Date: Sat, 19 Dec 2015 04:18:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.85.157] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:3hpMOv2NjWn/0rNoXa5Okq6LJ4eOmyx8VDIdQcVf1Hwggeaei53dV1cqZaB1unTv1+1K9yuNmelVPkXoJs7cvt9VvNDVcWI1xkQvM0hW6COiDAsXN0m/vfNyBZWE5udoZqaLlM1QYZ+/sqzGqoWUwA==; 24:tQISqTWSzHMyB3cyBSX9KA+rZzyrwQPlhq5Q1sN7o0fa1u5/gj/HYViJJhwWiyAZftANFiYzGEGpQHfKWvnhwaiUmGnIuKx4Ra7BIyy+asc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 07954CC105 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(189002)(199003)(74316001)(99286002)(106356001)(11100500001)(110136002)(105586002)(189998001)(97736004)(86612001)(50986999)(19617315012)(5002640100001)(86362001)(81156007)(33656002)(5001960100002)(10400500002)(5005710100001)(10290500002)(19625215002)(101416001)(5003600100002)(5004730100002)(230783001)(10090500001)(8990500004)(19300405004)(19580395003)(229853001)(16236675004)(2351001)(790700001)(92566002)(102836003)(3846002)(1730700002)(2900100001)(15975445007)(586003)(77096005)(6116002)(66066001)(1220700001)(1096002)(2501003)(76576001)(122556002)(5008740100001)(54356999)(87936001)(40100003)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4425323FBC27D5636C6D59CF5E20BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2015 04:18:37.8221 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Cc: Chris Lonvick Subject: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing remaining comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2015 04:19:01 -0000 --_000_BY2PR03MB4425323FBC27D5636C6D59CF5E20BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Proof-of-Possession Key Semantics for JWTs draft -11 addresses Sec-Dir revi= ew comments by Chris Lonvick and ballot comments by Stephen Farrell. This = should enable clearing the "point raised" status from yesterday's IESG tele= chat and progressing the document to the RFC Editor. The specification is available at: * http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-11 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-1= 1.html -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1518 and as= @selfissued. --_000_BY2PR03MB4425323FBC27D5636C6D59CF5E20BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Proof-of-Possession Key Semantics for JWTs draft -11= addresses Sec-Dir review comments by Chris Lonvick and ballot comments by = Stephen Farrell.  This should enable clearing the “point raised&= #8221; status from yesterday’s IESG telechat and progressing the document to the RFC Editor.

 

The specification is available at:

·       http://tools.ietf.org/html/draft-ietf-oa= uth-proof-of-possession-11

 

An HTML-formatted version is also available at:=

·       http://self-issued.info/docs/draf= t-ietf-oauth-proof-of-possession-11.html

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           -- Mike

 

P.S.  This note was also posted at http://self-issued.info/?p=3D1518 and as @selfissued.

--_000_BY2PR03MB4425323FBC27D5636C6D59CF5E20BY2PR03MB442namprd_-- From nobody Sun Dec 20 22:32:09 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757C01A89C4 for ; Sun, 20 Dec 2015 22:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.155 X-Spam-Level: X-Spam-Status: No, score=0.155 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKhYXwgFF4-O for ; Sun, 20 Dec 2015 22:32:05 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 762151A89B9 for ; Sun, 20 Dec 2015 22:32:05 -0800 (PST) Received: by mail-pa0-x233.google.com with SMTP id wq6so94446441pac.1 for ; Sun, 20 Dec 2015 22:32:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=iFxYBUxfy2kzlwPkWzZdhrAYMd70E1uhKXnWde6D3A4=; b=E6pcf/l2T25sRhrrOEvlC0hJDhCq6DnJA8U25MnwXjpKbWC89cJOgWQztpAzMKx5CH Kn30eIpRFoOdvyYcvjzkLHFGo93N8OWa/piTbBe9AxbJhw06xv8HZUZUPJ6SJOaOUAYf WKMP0PYSEFYnm7wKGngnxlgCtEkqB8AURGSPM2EVGE77Hr6PLmYE7UG+O0GVGEK1lUXF JRlmE8/6kF3GaD3IoK5z1E8tzzGfXvDz0+dNRTpMqfEltf+5gcE8EhXrh78BKwATnY3a qj9iW/LoNrgkiQUNVkgNA+2iGbizS2F81H3pht4zRKPffnZBG/f95PNEVu7LIrLnjnxL 3Eww== X-Received: by 10.66.100.163 with SMTP id ez3mr24739582pab.5.1450679525119; Sun, 20 Dec 2015 22:32:05 -0800 (PST) Received: from tovan.intra.gree-office.net ([27.110.57.140]) by smtp.gmail.com with ESMTPSA id e74sm29314428pfb.91.2015.12.20.22.32.03 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 20 Dec 2015 22:32:04 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_6F0CC499-1DE4-45C1-960F-1056FEF7BE22" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: nov matake In-Reply-To: Date: Mon, 21 Dec 2015 15:32:02 +0900 Message-Id: References: To: Mike Jones X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Token Exchange: An STS for the REST of Us X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 06:32:07 -0000 --Apple-Mail=_6F0CC499-1DE4-45C1-960F-1056FEF7BE22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mike, I=E2=80=99m planning to use Token Exchange spec for a use-case described = bewlow. 1. a native app obtains an access_token & an id_token from an IdP 2. the native app passes the id_token to its own backend component 3. the backend component obtains an access token from the IdP using the = id_token via token exchange In this use-case, the IdP will issue an id_token like below gist. https://gist.github.com/nov/d760b78c5cce8248b308 In the gist, =E2=80=9Ccnf=E2=80=9D and =E2=80=9Cscopes" claim comes from = OpenID Connect ACDC discussed in the NAPPS WG. = https://bitbucket.org/openid/napps/src/c22a2adb3f66f7a34fb5992857204987823= 90f7d/draft-acdc-01.txt?at=3Ddefault&fileviewer=3Dfile-view-default And now I realized ACDC defines =E2=80=9Cscopes=E2=80=9D claim and Token = Exchange defines =E2=80=9Cscp=E2=80=9D. In my case, the first id_token will includes =E2=80=9Cscopes=E2=80=9D = claim, and the access token issued to the client's backend component = includes =E2=80=9Cscp=E2=80=9D claim. It=E2=80=99s theoretically OK, but I prefer those two claims have the = same name=E2=80=A6 nov > On Dec 14, 2015, at 17:05, Mike Jones = wrote: >=20 > I=E2=80=99m happy to report that a substantially revised OAuth 2.0 = Token Exchange draft has been published that enables a broad range of = use cases, while still remaining as simple as possible. This draft = unifies the approaches taken in the previous working group draft and = draft-campbell-oauth-sts, incorporating working group input from the = in-person discussions in Prague and mailing list discussions. Thanks to = all for your interest in and contributions to OAuth Token Exchange! = Brian Campbell deserves special recognition for doing much of the = editing heavy lifting for this draft. > =20 > The core functionality remains token type independent. That said, new = claims are also defined to enable representation of delegation actors in = JSON Web Tokens (JWTs). Equivalent claims could be defined for other = token types by other specifications. > =20 > See the Document History section for a summary of the changes made. = Please check it out! > =20 > The specification is available at: > =C2=B7 = http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03 = > =20 > An HTML-formatted version is also available at: > =C2=B7 = http://self-issued.info/docs/draft-ietf-oauth-token-exchange-03.html = > =20 > -- Mike > =20 > P.S. This note was also posted at http://self-issued.info/?p=3D1509 = and as @selfissued = . > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_6F0CC499-1DE4-45C1-960F-1056FEF7BE22 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Mike,

I=E2=80=99m planning to use Token Exchange spec for a = use-case described bewlow.

1. a native app obtains an access_token & an id_token = from an IdP
2. the native app passes the id_token = to its own backend component
3. the backend = component obtains an access token from the IdP using the id_token via = token exchange

In this use-case, the IdP will issue an id_token like below = gist.
https://gist.github.com/nov/d760b78c5cce8248b308

In the gist, =E2=80=9Ccnf=E2= =80=9D and =E2=80=9Cscopes" claim comes from OpenID Connect ACDC = discussed in the NAPPS WG.
https://bitbucket.org/openid/napps/src/c22a2adb3f66f7a34fb59928= 5720498782390f7d/draft-acdc-01.txt?at=3Ddefault&fileviewer=3Dfile-view= -default

And= now I realized ACDC defines =E2=80=9Cscopes=E2=80=9D claim and Token = Exchange defines =E2=80=9Cscp=E2=80=9D.
In my case, = the first id_token will includes =E2=80=9Cscopes=E2=80=9D claim, and the = access token issued to the client's backend component includes =E2=80=9Csc= p=E2=80=9D claim.
It=E2=80=99s theoretically OK, = but I prefer those two claims have the same name=E2=80=A6

nov

On Dec 14, 2015, at 17:05, Mike Jones <Michael.Jones@microsoft.com> wrote:

I=E2=80=99m happy to report that a = substantially revised OAuth 2.0 Token Exchange draft has been published = that enables a broad range of use cases, while still remaining as simple = as possible.  This draft unifies the approaches taken in the = previous working group draft and draft-campbell-oauth-sts, incorporating = working group input from the in-person discussions in Prague and mailing = list discussions.  Thanks to all for your interest in and = contributions to OAuth Token Exchange!  Brian Campbell deserves = special recognition for doing much of the editing heavy lifting for this = draft.
 
The core functionality remains token type independent.  = That said, new claims are also defined to enable representation of = delegation actors in JSON Web Tokens (JWTs).  Equivalent claims = could be defined for other token types by other specifications.
 
See the = Document History section for a summary of the changes made.  Please = check it out!
 
The specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03
 
An = HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-ietf-oauth-token-exchange-03= .html
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike
 
P.S.  = This note was also posted at http://self-issued.info/?p=3D1509 and as @selfissued.
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_6F0CC499-1DE4-45C1-960F-1056FEF7BE22-- From nobody Tue Dec 22 00:03:59 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51341A701D for ; Tue, 22 Dec 2015 00:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.24 X-Spam-Level: * X-Spam-Status: No, score=1.24 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubInSE7aN1mm for ; Tue, 22 Dec 2015 00:03:54 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467B11A7020 for ; Tue, 22 Dec 2015 00:03:53 -0800 (PST) Received: from [192.168.10.142] ([80.92.114.181]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LgHvY-1aYZyn0LDw-00nfIN; Tue, 22 Dec 2015 09:03:45 +0100 To: Kepeng Li , "oauth@ietf.org" References: <5672DBE7.30101@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <567903E4.3070501@gmx.net> Date: Tue, 22 Dec 2015 09:03:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MrAMGgLp28FNVFf1Kt1j26T1LPCr3TRQF" X-Provags-ID: V03:K0:r1GxnD0ToL8wBr9LKwbQaOg+fauJjoQF/o3fGw5UUsb0f41xlxU gmHMq6oNZXro7hIvd4GHznseh23j0cR1btcF4kQPh+CPo5m+0vsjYk9MWeNa3zNgy6x8aJU iTYxKCGi/3LXwjSsHDecE2DwYThPEU8sT3XMlUZ0zNQo5m2efN8UR54dgSLbPQj1ZYFtsuI TbNIxzZw0+t0awXXVeovQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:xGiXI0QAn94=:gc3VVRaGhoTUzm4iAH2GKu 9rFjh2XxADVhOX/tXmn/9a8DCd+9COrpV5n+2gZoFStHCJOIuuhoauufR7RHb/MSDLJbpo586 C2B7BfitpK6NLAylSyD06uSABKeILpGFpKToXhDujeQU59p+jzpDomvVlwGoZwyFjVOD5JHsZ SCc405iij50V4t4Pgw/eGtfkGm8fI5MRE2rcaYNeBIRLYYPbM8cNf3n1R2DDOGTF+7vDYTuUw 2eeOOEqmChhFTnyZZ3YXiaggDMaOV26T12TpaKNSv7U2QRRNJSw2cQ6/YCIczBOVnWwAvokwD /hgN5BmM4q+4A9z5tjp2eoPmaQXtzubOv8FdBaCQ8dd0nPbzBjQIN6D7qqBeGUfmCVye2HqUi Cwg8MO0HTUg0iBaGJ+AbVUvyvzPtGOmRDjlbeUUGt3EdzVYq8KXpDRipu0NoXBgC1AY1HQKxi PPNuiMDbpl/Ivpun/V0m7azHC0It1JOWRttnSClYCxsA3OjKBOGHOQm0JPLIA52kdb57EyBIM PFd/0o0VmfayIEQDTZuSLf0DXrgkr/ofXtaCCsKLW6Z8ZrxtzDdLeC0DpkOfqUmLf7/lPto+o ETljflRvXT8FVF7wqp7PuUyuGAAopi8A7Xayx0no31hoLRpKpOShR8CYcsomG0w3PNPLgxUrO IZBn1SSMEI1JvEIlZRMaQ1g0fr6RaE34V/aWiAP0EwidK75n8Yhd+p9Aeu5goJND2cwboM41D ggAuqqbBahCeMsQtyf5hyVnSJcxvPKMUMkHWd+fJz9WL0IUQAEvAhlepldc= Archived-At: Subject: Re: [OAUTH-WG] OAuth Recharting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 08:03:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MrAMGgLp28FNVFf1Kt1j26T1LPCr3TRQF Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: quoted-printable Hi Kepeng, I intentionally kept the wording vague to have a bit of freedom when we do the call for adoption of specific documents. Having said that I will post a mail to the list to bring up a few concerns regarding the scope of the PoP work that have been brought to my attention. Ciao Hannes On 12/18/2015 01:59 AM, Kepeng Li wrote: > Hi Hannes, >=20 > Thanks for putting this together. >=20 >> and specifications that mitigate security attacks, such as Proof Key f= or >> Code Exchange. >=20 >=20 > I propose to change it to: >=20 > and specifications that mitigate security attacks, such as Proof Key fo= r > Code Exchange, and Sender Constraint JSON Web Token. >=20 >=20 > Sender Constaint JWT is mentioned in PoP architecture document, but it = is > not=20 > specified in detail. That is why we provided a separate draft for that.= >=20 >=20 > Thanks, >=20 > Kind Regards > Kepeng >=20 > =D4=DA 17/12/15 11:59 pm=A3=AC "Hannes Tschofenig" =D0=B4=C8=EB: >=20 >> Hi all, >> >> at the last IETF meeting in Yokohama we had a rechartering discussion >> and below is proposed text for the new charter. Please take a look at = it >> and tell me whether it appropriately covers the discussions from our >> last meeting. >> >> --------------- >> >> Charter Text >> >> The Web Authorization (OAuth) protocol allows a user to grant a >> third-party Web site or application access to the user's protected >> resources, without necessarily revealing their long-term credentials, >> or even their identity. For example, a photo-sharing site that >> supports OAuth could allow its users to use a third-party printing Web= >> site to print their private pictures, without allowing the printing >> site to gain full control of the user's account and without having the= >> user share his or her photo-sharing sites' long-term credential with >> the printing site. >> >> The OAuth 2.0 protocol suite already includes >> >> * a procedure for enabling a client to register with an authorization >> server, >> * a protocol for obtaining authorization tokens from an authorization >> server with the resource owner's consent, and >> * protocols for presenting these authorization tokens to protected >> resources for access to a resource. >> >> This protocol suite has been enhanced with functionality for >> interworking with legacy identity infrastructure (e.g., SAML), token >> revocation, token exchange, dynamic client registration, token >> introspection, a standardized token format with the JSON Web Token, an= d >> specifications that mitigate security attacks, such as Proof Key for >> Code Exchange. >> >> The ongoing standardization efforts within the OAuth working group >> focus on increasing interoperability of OAuth deployments and to >> improve security. More specifically, the working group is defining pro= of >> of possession tokens, developing a discovery mechanism, >> providing guidance for the use of OAuth with native apps, re-introduci= ng >> the device flow used by devices with limited user interfaces, addition= al >> security enhancements for clients communicating with multiple service >> providers, definition of claims used with JSON Web Tokens, techniques = to >> mitigate open redirector attacks, as well as guidance on encoding stat= e >> information. >> >> For feedback and discussion about our specifications please >> subscribe to our public mailing list. >> >> For security related bug reports that relate to our specifications >> please contact <>. If the reported bug >> report turns out to be implementation-specific we will >> attempt to forward it to the appropriate developers. >> >> --------------- >> >> >> Ciao >> Hannes >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 --MrAMGgLp28FNVFf1Kt1j26T1LPCr3TRQF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWeQPlAAoJEGhJURNOOiAtVJAH/3DNioKasQ8H3KO6QRD4lyGI 8MzKOXQuG1kyXSUVjwdNwk1h6SHWo8iitDlGnoUkteDsEWx84XWd7pRuG3w0jL5V tzLZiP2fPudZVNrVMuVFATP+MaolQHjyV3RF6Wx+AG/uJKgSrcyHF2xCQ3Ch29Ww k43HSdeiat8RbPt7UpT+NYWOOcvBnnv2kX/BNC465vXh0DNG3X+jDZKUaY/bbyxY fyCuFZ43cwBxAtCKyYh6QkcgVB/AcWMzjw8rmiv0gLIPfvSyza54M6vkwuU+5AbP LDFsRq43Yyqiqy7UIvttTFbrxDNgX+3SJRc9sgdXt3JRaj+dpZjSw9PRHWqz7+U= =Yy7B -----END PGP SIGNATURE----- --MrAMGgLp28FNVFf1Kt1j26T1LPCr3TRQF-- From nobody Mon Dec 28 06:40:33 2015 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5F21A00E1; Mon, 28 Dec 2015 06:40:28 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151228144028.6639.51315.idtracker@ietfa.amsl.com> Date: Mon, 28 Dec 2015 06:40:28 -0800 Archived-At: Cc: draft-ietf-oauth-proof-of-possession@ietf.org, oauth-chairs@ietf.org, The IESG , oauth@ietf.org, rfc-editor@rfc-editor.org Subject: [OAUTH-WG] Protocol Action: 'Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)' to Proposed Standard (draft-ietf-oauth-proof-of-possession-11.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 14:40:28 -0000 The IESG has approved the following document: - 'Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)' (draft-ietf-oauth-proof-of-possession-11.txt) as Proposed Standard This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ Technical Summary This specification defines how to express a declaration in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular key and that the recipient can cryptographically confirm proof-of- possession of the key by the presenter. This property is also sometimes described as the presenter being a holder-of-key. Working Group Summary The document was developed by the working group based on the requirements and architecture described in draft-ietf-oauth-pop-architecture. There is strong consensus behind this work. Document Quality There is at least one implementation of this draft confirmed on the OAuth mailing list. Personnel Kepeng Li is the document shepherd and Kathleen Moriarty is the responsible AD. IANA Note This specification establishes the IANA "JWT Confirmation Methods" registry for JWT "cnf" member values with Specification Required [RFC5226] and designated expert review on the oauth-pop-reg-review@ietf.org mailing list. CNF value is also added to the registry established in RFC7519