Hi Mike, sticking with working group document is fine.
However, the first example does not make sense to me. [maybe my brain is a bit empty at the moment] When is a JWT signed by the client and then sent to the Authorization Server other than in the Assertion draft that I mention in the second example? Ciao Hannes On 07/14/2014 06:16 PM, Mike Jones wrote: > I'd rather that we stayed with working group drafts in the examples. > So I would counter-propose the following text: > > "The public key(s) referenced by "jwks_uri" (or contained in the > "jwks") can be used in a variety of use cases. For example, the > signature of a JWT [I-D.ietf-json-web-token] signed by the client can > be verified by the authorization server using these keys. Another > example is that the authorization server can use the indicated public > keys to verify a request to the token endpoint that utilizes the JWT > assertion profile as described in Section 4.2 of > [I-D.ietf-oauth-assertions]." > > -- Mike > > -----Original Message----- From: OAuth > [mailto:[email protected]] On Behalf Of Hannes Tschofenig Sent: > Monday, July 14, 2014 2:42 AM To: Brian Campbell; John Bradley Cc: > [email protected] Subject: Re: [OAUTH-WG] Dynamic Client Registration: > jwks / jwks_uri > > What about the following text: > > jwks_uri > > .... <previous text in Section 2 of > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-18> ..... > > "The public key(s) referenced by jwks_uri (or contained in the jwks) > can be used in a variety of use cases. For example, the AS can use > the indicated public key to verify a request to the token endpoint > that utilizes the JWT assertion profile as described in Section 4.2 > of [I-D.ietf-oauth-assertions]. Another use case is for the AS to use > the public key of a client to encrypt a symmetric proof-of-possession > key sent to the client, as described in Section 4.2 of > [I-D.bradley-oauth-pop-key-distribution]." > > > Ciao Hannes > > > > > > > > On 07/08/2014 09:43 PM, Brian Campbell wrote: >> +1 to John's #3. The others could maybe be described in somewhat >> abstract terms as examples of those "higher level protocols that >> use signing or encryption." >> >> On Tue, Jul 8, 2014 at 12:33 PM, John Bradley <[email protected]> >> wrote: >>> In Connect these public keys are used to: 1 verify the signature >>> of request objects (Signed Requests), something not in OAuth yet, >>> and part of what the description calls higher level protocols. 2 >>> encrypt the responses from the user_info endpoint or id_token >>> (also not part of OAuth directly at this point) >>> >>> 3 validate requests to the token endpoint authenticated by the >>> JWT assertion profile I think this is legitimate OAuth use. >>> >>> Whew for the PoP specs: 4 used to encrypt the symmetric proof key >>> in a JWK sent to the client >>> http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-0 >>> >>> 1#page-7 >>> 5 used to provide a PoP key for the client to the AS as part of >>> registration rather than passing the JWK on each request to the >>> token endpoint. >>> >>> So the keys in the JWK can be used a number of ways by the AS. >>> >>> I think we could reference 3 and 4 as examples to be safe. >>> >>> John B. >>> >>> >>> On Jul 8, 2014, at 3:04 PM, Mike Jones >>> <[email protected]> wrote: >>> >>>> Was there specific language that had been discussed to be added >>>> for this? If not, could someone please create some? >>>> >>>> Thanks, -- Mike >>>> >>>> -----Original Message----- From: OAuth >>>> [mailto:[email protected]] On Behalf Of Hannes Tschofenig >>>> Sent: Tuesday, July 08, 2014 5:09 AM To: [email protected] >>>> Subject: [OAUTH-WG] Dynamic Client Registration: jwks / >>>> jwks_uri >>>> >>>> Hi all, >>>> >>>> in my earlier review I had noted that the semantic of the >>>> fields is underspecified, i.e., it is not clear what these >>>> fields are used for. >>>> >>>> In private conversations I was told that an informal reference >>>> to a potential use case will be added. I don't see such >>>> reference with version -18. >>>> >>>> Ciao Hannes >>>> >>>> _______________________________________________ OAuth mailing >>>> list [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ OAuth mailing >>> list [email protected] https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ OAuth mailing list >> [email protected] https://www.ietf.org/mailman/listinfo/oauth >> >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
