[Openid-specs-ab] First Release Candidates for final OpenID Connect specifications
torsten at lodderstedt.net
Sun Oct 20 19:00:10 UTC 2013
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,
> 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 126.96.36.199 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.
> "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."
> 188.8.131.52. 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
> "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
> "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
> 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?
> 184.108.40.206. 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.
> 220.127.116.11. 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.
> 18.104.22.168. 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.
> 22.214.171.124. 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).
> 126.96.36.199. Token Request Validation
> The whole sections seems to re-phrase standard OAuth stuff. I
> recommend to remove it.
> 188.8.131.52. 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
> "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."
> 184.108.40.206. 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
> 220.127.116.11. 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.
> 18.104.22.168. Access Token Validation
> I would recommend to add the text from section 22.214.171.124. 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."
> 126.96.36.199. Authorization Request
> see comments regarding redirect_uri and nonce for section 188.8.131.52
> 184.108.40.206 - 220.127.116.11 - 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?
> 18.104.22.168. Authorization Successful Response
> access_token Parameter - "Access Token for the UserInfo Endpoint." -
> In contrast to section 22.214.171.124, 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.
> 126.96.36.199. 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"
> 188.8.131.52. ID Token Validation
> Text around signature validation should be moved from 184.108.40.206 to this
> section as it is required for the implicit grant (in contrast to code).
> 2.3. Authentication using the Hybrid Flow
> 220.127.116.11.-18.104.22.168. can be removed
> 22.214.171.124. Authorization Successful Response
> Again, I would recommend to focus on additional response parameters,
> as in section 126.96.36.199
> 188.8.131.52. Redirect URI Fragment Handling
> see comment at section 184.108.40.206
> I think 220.127.116.11.-18.104.22.168 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
> 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
> 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
> 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
> 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:
> Also, two implementer's guides are also available to serve as
> self-contained references for implementers of basic Web-based
> Relying Parties:
> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab