[Openid-specs-ab] First Release Candidates for final OpenID Connect specifications

Torsten Lodderstedt torsten at lodderstedt.net
Sun Oct 20 19:00:10 UTC 2013

Hi Mike,

I will give these specs a read before IETF-88.


Am 19.10.2013 23:32, schrieb Mike Jones:
> Thanks a bunch, Torsten.  Permit me to make the same ask I made of 
> Vladimir after he sent his review of core -- could you please also 
> read Discovery, Registration, and Multiple Response Types? They've 
> been reviewed less than Core has and would be shocked if improvements 
> couldn't be made to them as well.
> Thanks again,
> -- Mike
> *From:*Torsten Lodderstedt [mailto:torsten at lodderstedt.net]
> *Sent:* Friday, October 18, 2013 1:16 PM
> *To:* Mike Jones
> *Cc:* openid-specs-ab at lists.openid.net; board at openid.net
> *Subject:* Re: [Openid-specs-ab] First Release Candidates for final 
> OpenID Connect specifications
> Hi all,
> @Mike: first of all let me thank you for taking the burden and rework 
> the whole document structure. I think the new structure is a major 
> leap forward for OpenID Connect.
> I focused my review on the new core specification. Please find my 
> comments below.
> I won't attend IIW but will attend IETF-88. So, if needed, we can talk 
> through my comments there.
> Best regards,
> Torsten.
> 1.  Introduction
> I would suggest to a reference to RFC 6749 in the first sentence. It 
> probably also makes sense to explicitly point out that the reader is 
> expected to be familiar with RFC 6749 and RFC 6750 as well as other 
> IETF I-Ds (notably JOSE,  JWT and JWT Assertion Profile).
> 1.3.  Overview
> The flow description is a good starting point for readers. I would 
> suggest to add the following information in this section:
> - OpenID Connect authentication is basically an extension to the 
> standard OAuth authorization process. This extension is defined for 
> most OAuth grant types.
> - Clients wishing to acquire identity information indicate this by 
> sending the scope value "openid" as part of the authorization request 
> parameters. (There are much more parameters used to control the 
> process but this is the "main switch".)
> - Such a client is also called relying party (RP). An authorization 
> server also supporting OpenID Connect is called OpenID Provider (OP).
> Adding this information will help the reader to understand the way 
> connect utilizes/integrates into OAuth.
> I would also suggest to move the definition (syntax and contents) of 
> the ID Token here and make it section 1.4 because this is THE core 
> concepts used throughout the specification. It's introduction in 
> section is to late (in my opinion) because it is cited roughly 
> 20 times in previous sections.
> 2.  Authentication
> "The Authorization Code Flow is suitable for Clients that can securely 
> maintain a Client Secret between themselves and the Authorization 
> Server ..." - this is confusing since public clients can use the code 
> as well. The key benefits of this grant type in my opinion are:
> - AS _can_ authenticate clients
> - AS _can_ return refresh tokens
> - simplest way for web application backends to acquire tokens
> That's why is best suited for web applications and native apps.
> Proposal:
> "The Authorization Code Flow is appropriate for web applications and 
> native apps as it allows to authenticate clients and obtain refresh 
> tokens whereas the implicit flow does not support these features."
> Or just remove the assessment of OAuth grant types and leave it to the 
> implenentors to carry out their assessment.
> 2.1.  Authentication using the Authorization Code Flow
> OLD: "This provides the benefit of not exposing the Access Token to 
> the Resource Owner ..."
> The same indeed holds for the ID Token, which is more important from a 
> security perspective.
> NEW: "This provides the benefit of not exposing the Access Token and 
> the ID Token to the Resource Owner ..."
> NEW (alternative): "This provides the benefit of not exposing any 
> Token to the Resource Owner ..."
> 2.1.1.  Authorization Code Flow Steps
> OLD: "8. Client validates the tokens and retrieves the End-User's 
> subject identifier."
> I assume the client is supposed to validate the ID token, only?
> NEW: "8. Client validates the ID token and retrieves the End-User's 
> subject identifier."
>  Authorization Request
> "When the Client wishes to access a Protected Resource and the 
> End-User Authorization has not yet been obtained, the Client prepares 
> an Authorization Request to the Authorization Endpoint" - Why is this 
> relevent in this context? I suggest to remove this sentence.
> "An Authorization Request is a message sent from an RP to the OP's 
> Authorization Endpoint. It is an extended OAuth 2.0 [RFC6749] 
> Authorization Request. Section 4.1.1 and 4.2.1 of OAuth 2.0 [RFC6749] 
> define the OAuth 2.0 Authorization Request parameters." - Why 
> Authorization Request? Shouldn't this be called an "Authentication 
> Request"?
> "Communication with the Authorization Endpoint MUST utilize TLS. See 
> Section 15.17 for more information on using TLS.
> Authorization Servers MUST support the use of the HTTP GET and POST 
> methods defined in RFC 2616 [RFC2616] at the Authorization 
> Endpoint.Clients MAY use the HTTP GET or POST methods to send the 
> Authorization Request to the Authorization Server. If using the HTTP 
> GET method, the request parameters are serialized using URI Query 
> String Serialization, perSection 12.1. If using the HTTP POST method, 
> the request parameters are serialized using Form Serialization, per 
> Section 12.2."
> Seems to be standard OAuth stuff, I suggest to remove it.
> - redirect_uri Parameter
> "This URI MUST exactly match one of the redirect_uris registered for 
> the Client" - Why is the redirect_uri validation more restrictive than 
> http://tools.ietf.org/html/rfc6749#section-
> "When using this flow, the redirection URI MAY use the http scheme, 
> provided that the Client Type is confidential, as defined in Section 
> 2.1 of OAuth 2.0; otherwise, it MUST use the https scheme" - This, 
> surprisingly enough, is relaxed in comparison to 
> http://tools.ietf.org/html/rfc6749#section-10.5.
> RFC 6749 states: "Authorization codes operate as plaintext bearer 
> credentials, used to verify that the resource owner who granted 
> authorization at the authorization server is the same resource owner 
> returning to the client to complete the process.  Therefore, if the 
> client relies on the authorization code for its own resource owner 
> authentication, the client redirection endpoint MUST require the use 
> of TLS."
> Why is Connect, in this particular case, less restrictive than OAuth?
> - nonce Parameter
> "One method to achieve this is to store a random value as a signed 
> session cookie, and pass the value in the nonce parameter. In that 
> case, the nonce in the returned ID Token can be compared to the signed 
> session cookie to detect ID Token replay by third parties." - I would 
> recommend to move this text into an "implementation note" section
> id_token_hint Parameter - "Previously issued ID Token passed to the 
> Authorization Server .." issued by the AS being requested? or any AS? 
> I assume by the same AS
> NEW: "ID Token previously issued by this Authorization server to the 
> client ..."
> "... it SHOULD return a login_required error." - Does this mean the OP 
> shall try to authenticate the user account identified by the ID token 
> and refuses authentication otherwise? This sounds more like a 
> requirement than a hint.
> "When possible, an id_token_hint SHOULD be present when prompt=none is 
> used and an invalid_request error MAY be returned if it is not; 
> however, the server SHOULD respond successfully when possible, even if 
> it is not present."  - Why is the login hint recommended for this 
> prompt value? checkid_immediate in OpenID 2.0 worked very well w/o a hint?
>  Authorization Request Validation
> "3. If the sub (subject) Claim is requested with a specific value for 
> the ID Token ...." The meaning of the text is unclear to me. How is a 
> specific sub value requested? by the login_hint or the id_token_hint?
> "As specified in OAuth 2.0 [RFC6749], Authorization Servers SHOULD 
> ignore unrecognized request parameters.
> If the Authorization Server encounters any error, it MUST return an 
> error response."
> Standard OAuth stuff, I recommend to remove it.
>  Authorization Server Obtains End-User Consent/Authorization
> "When permitted by the request parameters used, this MAY be done 
> through an interactive dialogue with the End-User ..." - What if the 
> parameters do not allow for an interactive dialogue, e.g. 
> prompt==none? I assume an error response with return code 
> consent_required or interaction_required is appropriate. I would 
> prefer interaction_required because to RP does not need to know more.
>  Authorization Successful Response
> This is a vanilla OAuth 2.0 response, right? I would suggest to just 
> say so.
> BTW: This piece of text is not applicable to the code grant type: 
> "This specification only describes OAuth 2.0 Bearer Token Usage 
> [RFC6750]. The OAuth 2.0 response parameter token_type MUST be set to 
> Bearer unless another Token Type has been negotiated with the Client."
> 2.1.3.  Tokens Endpoint
> "Clients MUST use the HTTP POST method to make requests to the Token 
> Endpoint. Request parameters are added using Form Serialization, per 
> Section 12.2. The Token Endpoint MUST support the use of the HTTP POST 
> method defined in RFC 2616 [RFC2616] at the Token Endpoint.
> Communication with the Token Endpoint MUST utilize TLS. See Section 
> 15.17 for more information on using TLS.
> All Token Endpoint responses that contain tokens, secrets, or other 
> sensitive information MUST include the following HTTP response header 
> fields and values: ..."
> This seems to be standard OAuth stuff. I recommend to remove it.
>  Token Request
> "To obtain an ID Token, Access Token, or Refresh Token, the Client 
> MUST authenticate to the Token Endpoint using the authentication 
> method registered for its client_id, as described in Section 8 ..." - 
> At this point the reader is not familiar with the different 
> authentication methods supported by an OpenID OP. I therefore suggest 
> to move the client authentication section before the authentication 
> section (e.g. make it a section 1.5).
>  Token Request Validation
> The whole sections seems to re-phrase standard OAuth stuff. I 
> recommend to remove it.
>  Token Successful Response
> "Servers SHOULD support OAuth 2.0 Bearer Token Usage [RFC6750] for 
> interoperability" - I think this topic is better covered in the MTI 
> section.
> "the following parameters MUST be included in the response if the 
> grant_type value is authorization_code and the Authorization Request 
> scope parameter contains openid:" - Seems to be redundant since this 
> whole section is about exactly this use case. I recommend to remove 
> this text. Same holds true for the following text
> "An id_token MUST be returned when the grant_type value is 
> authorization_code and MAY be returned when other grant types are used."
>  ID Token
> That's the key elements of OpenID Connect! As already stated, I 
> recommend to move the (full) description of its content and syntax to 
> section 1 (section 1.4). I think this will facilitate readability. The 
> validation rules should stay in the sections of the respective grant 
> types.
>  ID Token Validation
> "1. If the Client has provided an id_token_encrypted_response_alg 
> parameter during Registration, decrypt the ID Token using the key pair 
> specified during Registration." - text depends on dynamic registration 
> and should therefore be generalized.
> NEW: "1. If the ID Token is encrypted, the Client first decrypts it 
> using the key agreed upon with the authorization server."
> "5. If the id_token is received via direct communication between the 
> Client and the Token Endpoint, the TLS server validation MAY be used 
> to validate the issuer in place of checking the token signature. The 
> Client MUST validate the signature of all other ID Tokens according to 
> JWS [JWS] using the algorithm specified in the alg parameter of the 
> JWT header." - text seems rather generic. As this is about the code 
> flow, the ID token is received via direct communication, so the text 
> can be simplified.
> NEW: "5. Since the ID token is received via direct communication, the 
> TLS server validation MUST be used to validate the issuer in place of 
> checking the token signature."
> Steps 6-8 can be removed.
>  Access Token Validation
> I would recommend to add the text from section because this 
> is the first point where the concept is used.
> a_hash validation is mentioned. What's about c_hash validation?
> 2.2.  Authentication using the Implicit Flow
> "...which may expose them to the Resource Owner and other applications 
> that have access to the Resource Owner's User-Agent." - I recommend to 
> add: "In contrast to the authorization code flow, this requires 
> additional security mechanisms (described below) to detect falsified 
> ID tokens."
>  Authorization Request
> see comments regarding redirect_uri and nonce for section
> - - I recommend to state in section 2.2.2 that those 
> steps are performed in the same manner as for the code flow and to 
> remove these section?
>  Authorization Successful Response
> access_token Parameter - "Access Token for the UserInfo Endpoint." - 
> In contrast to section, this section also described standard 
> OAuth response parameters. I don't think this is needed. Moreover, the 
> term "User Info" is used before it is really introduced. In my 
> opinion, authentication should not talk about user info. The access 
> token returned as part of the authentication result might suited for 
> interactions with any protected resource, including user info.
>  Redirect URI Fragment Handling
> This section needs a bit more of context and description. While the 
> introduction of 2.2 states: "The Implicit Flow is mainly used by 
> Clients implemented in a browser using a scripting language", this 
> section suddenly _requires_ the client to send data to a web server 
> ("The Client MUST provide ...").
> First of all, I don't understand the MUST.
> Second, a description is needed of the different patterns, scripting 
> clients vs. scripted frontends of server-based web-application (here 
> the implicit grant offers better performance and scalability at the 
> cost of a more complex client implementation. Therefore, 
> implementation advices are given.
> I also think this section should be part of an "implementation note" 
> section.
>  ID Token Validation
> Text around signature validation should be moved from to this 
> section as it is required for the implicit grant (in contrast to code).
> 2.3.  Authentication using the Hybrid Flow
> can be removed
>  Authorization Successful Response
> Again, I would recommend to focus on additional response parameters, 
> as in section
>  Redirect URI Fragment Handling
> see comment at section
> I think can be removed - Instead it should be stated 
> that for the hybrid flow client and AS must conform to ALL 
> requirements for code and implicit.
> 3.  Initiating Login from a Third Party
> I assume this is mainly intended to support OP initiated logins? I 
> don't think it deserves a top-level section. I would recommend to make 
> it part of the Authentication section.
> "The Client MAY optionally register [OpenID.Registration] an 
> initiate_login_uri that can be used by the Authorization Server or 
> another party to initiate a login for an End-User at the Client." I 
> assume this feature shall also be supported by OPs w/o dynamic 
> registration? I therefore suggest to move this text to the dynamic 
> registration spec. Instead one could state: "The approach utilized by 
> the 3rd party or the OP to determine the client's respective URL is 
> out-of-scope of this document."
> Generally, I don't think any meta data element registered via dynamic 
> registration or discovered via OpenID Discovery should be 
> specified/mentioned in the core spec. I think the core function must 
> work w/o both functions in place.
> 4.  Claims
> "This section specifies how the Client can obtain Claims about the 
> End-User ..." claims about the authentication process are supported as 
> well.
> NEW: "This section specifies how the Client can obtain Claims about 
> the End-User and the authentication process ...
> 4.1.  Requesting Claims using Scope Values
> This is an extension to the authentication part, it should be 
> specified that way. For example, there is no need to specify the use 
> of the scope value "openid" again. IMHO it suffices to say that 
> clients may request access to user data by adding more scope values in 
> conjunction with "openid".
> 4.2.  Standard Claims
> I think this section should be the first section as it describes 
> standard claims on a conceptual level and which ways exist for a 
> client to retrieve them.
> 4.3.  UserInfo Endpoint
> I think this section should be merged with Section 4.1 as the scope 
> values defined there control access to this resource, only.
> 4.4.  Requesting Claims Locales with the "claims_locales" Request 
> Parameter
> I would suggest to move this either before 4.1. or after 4.5. as it 
> seems to be orthogonal to the functions described there.
> 4.6.  Claim Types
> This seems to be out of order because after a description of how a 
> client may allocate claims to ID token and user info, this section 
> again exclusively talks about UserInfo. Is it really the intention to 
> support aggregated and distributed claims at the User Info endpoint, 
> only? If so I recommend to move this section before 4.4. Otherwise, 
> please state that such claims can be provided in the ID Token as well.
> How is a aggregated or distributed claim requested by a client?
> 5.  Passing Request Parameters as JWTs
> I would suggest to move this topic into another document. The features 
> described here allow implementors to achieve higher security levels 
> and may reduce the request size but I consider them beyond the scope 
> of a core document.
> 6.  Self-Issued OpenID Provider
> How mature is the concept? How many implementations exist? Is this 
> really part of a core specification or rather an extension for 
> mobile/personal devices? I would opt for making this section a 
> separate document.
> 6.2.  Self-Issued OpenID Provider Registration
> "When using a Self-Issued OP, the Client is deemed to have registered 
> with the OP and obtained following Client Registration Response." - 
> Does this mean dynamic registration is required for self-issued ID 
> providing?
> 7.  Subject Identifier Types
> This section is completely about discovery and registration - it 
> should go there, consequently.
> 8.  Client Authentication
> This section provides fundamental information about the client 
> authentication methods supported/introduced by OpenID Connect. I would 
> suggest to move it into section 1 (e.g. section 1.5).
> "During Client Registration, the RP (Client) MAY register an 
> authentication method. " I assume all client authentication methods 
> shall work even if the OP does not support dynamic registration. 
> Consequently, this text must be replaced by a general description of 
> what methods are supported and how the OP is supposed to determine the 
> right method for a particular client.
> OLD: "During Client Registration, the RP (Client) MAY register an 
> authentication method. If no method is registered, the default method 
> of client_secret_basic MUST be used."
> NEW: "OpenID connect supports the authentication methods listed below. 
> The authorization server determines the authentication method to be 
> used in a particular authorization transaction based on the client_id. 
> The way client and authorization server negotiate the authentication 
> method is out of scope of this specification."
> 9.  Signatures and Encryption
> Most of this section talks about discovery and dynamic registration - 
> it should go there, consequently.
> I think the core spec needs MTI algorithms and clear definition when 
> signatures are required. In my opinion, there are two use cases:
> - Login via implicit grant
> - azp - Login at another AS via ID token
> In both cases, Signing ID Tokens with RSA SHA-256 could be good 
> baseline. This could be documented in the ID Tokens section or the MTI 
> section.
> 9.3.1.  Rotation of Asymmetric Signing Keys
> Isn't this an implementation note?
> 10.  Offline Access
> Given the description (" that grants access to the End-User's UserInfo 
> Endpoint ..."), I would say this text can go to the User Info section.
> 11.  Using Refresh Tokens
> I think this should go to the authentication section (2.4?), as it 
> describes usage of the refresh token grant type in the Connect context.
> 11.2.  Refresh Successful Response
> "If an ID Token is returned as a result of a token refresh request 
> ..." - Can't we specify the conditions under which an ID token is 
> returned? Otherwise, an interoperable client does not know what to 
> expect or how to control the outcome of this request. For the standard 
> authentication flow, presence of the scope value "openid" is the 
> trigger. I would suggest to use the same logic for the refresh token 
> grant type.
> 14.  Implementation Considerations
> I would suggest to move MTI requirements to another document as it 
> refers to nearly every document of the OpenID Connect suite. For the 
> core document, I would suggest to (at most) specify the MTI 
> requirements for closed systems, only:
> - code flow extension
> - prompt
> - display
> - language
> 14.1.  Mandatory to Implement Features for All OpenID Providers
> "Signing ID Tokens with RSA SHA-256" - I think, in Berlin, we agreed 
> to not require signatures for simple, static setups using authz code. 
> We agreed to move this to the MTI section for dynamic OPs.
> 14.5.  Compatibility Notes
> Isn't such information better covered on the working group page. Such 
> information typically change more often than the specification itself.
> 14.6.  Related Specifications and Implementer's Guides
> same here
> -------------------------------------------------------------------------------------------------------------------------
> Am 15.10.2013 17:18, schrieb Mike Jones:
>     I'm pleased to announce that the first release candidate versions
>     for final OpenID Connect specifications have been published.  The
>     complete set of specifications has been updated to resolve all
>     issues that had been filed against the specs being finished.
>     Please review these this week, in time for the in-person working
>     group meeting on Monday
>     <http://openid-wg-oct-2013.eventbrite.com/>.  Besides publishing
>     the specs in the usual formats, I've also created a Word version
>     of the core spec with tracked changes turned on to facilitate
>     people marking it up with specific proposed text changes.  If
>     you're in the working group, please download it
>     <http://self-issued.info/docs/openid-connect-core-1_0-14.docx> and
>     make any corrections or changes you'd like to propose for the
>     final specification.
>     The release candidate spec versions are:
>     ·http://openid.net/specs/openid-connect-core-1_0-14.html
>     ·http://openid.net/specs/openid-connect-discovery-1_0-18.html
>     ·http://openid.net/specs/openid-connect-registration-1_0-20.html
>     ·http://openid.net/specs/openid-connect-session-1_0-16.html
>     ·http://openid.net/specs/oauth-v2-multiple-response-types-1_0-09.html
>     Also, two implementer's guides are also available to serve as
>     self-contained references for implementers of basic Web-based
>     Relying Parties:
>     ·http://openid.net/specs/openid-connect-basic-1_0-29.html
>     ·http://openid.net/specs/openid-connect-implicit-1_0-12.html
>     Thanks to Nat for the early feedback. The structure of Core has
>     been changed somewhat since -13 to adopt some of his suggestions.
>     -- Mike
>     P.S.  I also posted about this at http://self-issued.info/?p=1140
>     <http://self-issued.info/?p=1140> and as @selfissued.
>     _______________________________________________
>     Openid-specs-ab mailing list
>     Openid-specs-ab at lists.openid.net  <mailto:Openid-specs-ab at lists.openid.net>
>     http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131020/5b2de616/attachment-0001.html>

More information about the Openid-specs-ab mailing list