The Connect text is lacking detail on why you might have different values for "iss" and client_id. We should cover that in more detail in this.
That is one good thing about going back and focusing on a specific part of the spec to pull it out into a separate spec is that it raises questions, that might have been glossed over in the larger context. John B. > On Nov 27, 2014, at 6:04 PM, Sergey Beryozkin <[email protected]> wrote: > > Hi John > On 27/11/14 19:22, John Bradley wrote: >> In sec 6 of openID Connect core we have. >> >> So that the request is a valid OAuth 2.0 Authorization Request, values for >> the response_type and client_id parameters MUST be included using the OAuth >> 2.0 request syntax, since they are REQUIRED by OAuth 2.0. The values for >> these parameters MUST match those in the Request Object, if present. >> >> So we should add that in to this text to make it clear that it must still be >> a well formed OAuth 2 request. >> > Thanks for the clarification, I did assume, while prototyping the client_id > was available as a dedicated query parameter too >> In Connect we do allow for the possibility that a 3rd party might sign a >> request object. >> >> An example was that in some jurisdictions it may be a 3rd party like a >> privacy commissioner that signs the request object so that the IdP know that >> the RP is allowed to request those claims. >> >> The processing by the AS is validate the signature based on the "iss" >> (typically the client) Compare the client_id to the iss and see if the iss >> is authoritative for value of the client_id claim (typically one to one). >> Compare the client_id claim value with the query parameter client_id value >> and reject if not the same. (you could do that first if you want) >> >> The idea of the hash is that allows the AS discover if the content of the >> request file has changed without getting it. >> >> The example from connect is: >> >> >> https://client.example.org/request.jwt#GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM >> >> The server needs to remember the full URI of the request object and refetch >> it when the fragment changes. >> >> Without the fragment the AS would need to rely on http:caching and at-least >> to a HEAD each time. >> >> That section can be expanded. >> > Very nice explanation above, thanks, sorry I did not do my home work and > reviewed the connect text :-). > > Thanks, Sergey > >> John B. >> >> >> >>> On Nov 27, 2014, at 2:55 PM, Sergey Beryozkin <[email protected]> wrote: >>> >>> Hi >>> >>> Should the text require that a "client_id" parameter is always included as >>> a query parameter too ? >>> >>> If it is only inside a 'request' parameter then how the server would >>> identify a client specific key that can be used to validate the signature ? >>> >>> Or is the idea that if it is JWS and no client_id query parameter is >>> available then a client id is extracted first, the key is identified and >>> then the signature is validated ? >>> >>> Also, a simple example how an optional file hash is specified when a >>> request_uri is used would be useful >>> >>> Many thanks, Sergey >>> On 13/11/14 04:07, [email protected] 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 : Request by JWS ver.1.0 for OAuth 2.0 >>>> Authors : Nat Sakimura >>>> John Bradley >>>> Filename : draft-ietf-oauth-jwsreq-01.txt >>>> Pages : 9 >>>> Date : 2014-11-12 >>>> >>>> Abstract: >>>> The authorization request in OAuth 2.0 utilizes query parameter >>>> serialization. This specification defines the authorization request >>>> using JWT serialization. The request is sent through "request" >>>> parameter or by reference through "request_uri" parameter that points >>>> to the JWT, allowing the request to be optionally signed and >>>> encrypted. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-oauth-jwsreq-01 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-01 >>>> >>>> >>>> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
