[Openid-specs-ab] Openid connect registration review

Richer, Justin P. jricher at mitre.org
Sat Oct 26 16:27:01 UTC 2013


On Oct 26, 2013, at 7:49 AM, George Fletcher <gffletch at aol.com> wrote:

> 
>> 
>> See file attached to this message
>> 
>> File: OpenID Connect Registration - draft 20 - flattened.pdf
>> 
>> Annotation summary:
>> 
>> --- Page 2 ---
>> 
>> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> co-resident
>> 
>> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> Does co-resident mean the same as the /token API  endpoint? Or just on the same server? Overloading the /token endpoint seems like a bad idea.

While I, and many others, agree with this, there were several parties who wanted everything to go through the token endpoint. All that this sentence is saying is that you could do that with this draft, if you were crazy  enough to want to.

>> 
>> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> Could (or should) these endpoint also be optionally returned in the openid connect discovery JSON response?
>> 
>> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> Client Registration Endpoint
>> 
>> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> Client Configuration Endpoint
>> 
>> 
>> --- Page 4 ---
>> 
>> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> Providers that use pairwise sub (subject) values SHOULD provide a sector_identifier_uri.
>> 
>> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> This sentence doesn't make sense to me. I think the point is that providers that support pair wise 'sub' identifiers must support client registered sector_identifier_uri values.
>> 
>> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> id_token_signed_response_alg
>> 
>> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> This implies to me that the client gets to dictate what algorithm is going to be used to sign the ID Token. That seems the opposite of all the other cases where the server gets to chose. Is the expected response a registration failure if the client requests an alg not supported by the AS?

Either a failure or the AS gets to dictate in its response, as with other values. This is just the client expressing its preference and the server expressing the actual value.

>> 
>> 
>> --- Page 5 ---
>> 
>> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> userinfo_signed_response_alg
>> 
>> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> If this value is not specified, then the default is that user info responses are NOT signed?

I believe it can be service specific if not otherwise specified, but that's a reasonable default.

>> 
>> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> If this is specified the response will be  [JWT] serialized, and encrypted using JWE. userinfo_encrypted_response_enc OPTIONAL. JWE enc algorithm  REQUIRED for encryption of UserInfo Responses. If userinfo_encrypted_response_alg is specified the default for this value is A128CBC-HS256. If this is requested in combination with signing the response will be signed then encrypted. If this is specified the response will be  [JWT] serialized, and encrypted using JWE. request_object_signing_alg OPTIONAL.  [JWS] alg algorithm  that MUST be used for signing Request Objects sent to the Authorization Server. All Request Objects from this client_id MUST be rejected if not signed with this algorithm. Servers SHOULD support RS256. The value none MAY be used. token_endpoint_auth_method OPTIONAL. Requested authentication method for the Token Endpoint. The options are client_secret_post, client_secret_basic, client_secret_jwt, and private_key_jwt, as described in Section 8 of [OpenID.Core]. Other authentication methods MAY be defined by extensions. If omitted, the default is client_secret_basic -- the HTTP Basic Authentication Scheme specified in Section 2.3.1 of  [RFC6749]. token_endpoint_auth_signing_alg OPTIONAL.  [JWS] alg algorithm  that MUST be used for signing the JWT used to authenticate the Client at the Token Endpoint for the private_key_jwt and client_secret_jwt authentication methods. All Token Requests using these authentication methods from this client_id MUST be rejected if the JWT is not signed with this algorithm. Servers SHOULD support RS256. The value none MUST NOT be used. default_max_age OPTIONAL. Default Maximum Authentication Age. Specifies that the End-User MUST be actively authenticated if the End-User was authenticated longer ago than the specified number of seconds. The max_age request parameter overrides this default value. require_auth_time OPTIONAL. Boolean value specifying whether the auth_time Claim in the id_token is REQUIRED. It is REQUIRED when the value is true. The auth_time Claim request in the Request Object overrides this setting. default_acr_values OPTIONAL. Default requested Authentication Context Class Reference values. Array of
>> 
>> OpenID Connect Discovery 1.0
>> 
>> [JWA]
>> 
>> [JWA]
>> 
>> JWT
>> 
>> [JWA] JWT
>> 
>> JWE [JWA]
>> 
>> JWT
>> 
>> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> This wording is used many times for these different responses that can be both signed and/or encrypted. I'm wondering if this sentence should include something like....If this option is specified when no signing algorithm is specifed, then ...
>> 
>> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> request_object_signing_alg
>> 
>> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> Do we need to specify a default?
>> 
>> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> default_max_age
>> 
>> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> As an OP I'm not sure I want to honor this parameter from a client. I'm assuming that the OP can ignore any parameter from the client it wants and just not return any value for that parameter in the response.
>> 
>> 
>> --- Page 6 ---
>> 
>> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> initiate_login_uri
>> 
>> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> Would a reference to the relevant section of core be useful here? I don't remember this flow very well and this is the first mention of target_link_uri in this document.
>> 
>> 
>> --- Page 8 ---
>> 
>> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> send
>> 
>> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> 'send' should be 'sent'
>> 
>> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> HTTP/1.1 200 OK
>> 
>> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> I think this should be a 201 response instead of a 200.
>> 
>> 
>> --- Page 12 ---
>> 
>> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:
>> It seems like there is some pretty complicated OP logic required to process the sector_identifier_uri. Given that the the list of allowed redirect_uris in the JSON file can change at any time! the OP would need to pull the file and verify that the current client redirect_uri is still present in the list. That is too much over head to do at token issuance. Should we have some guidance that redirect_uris can be added to the sector_identifier_uri file but SHOULD NOT be removed. Removing a redirect_uri from the file results in undefined behavior? With this guidance the OP can do all the  necessary checking at client registration time which seems reasonable.
>> 
>> 
>> (report generated by GoodReader)
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> George Fletcher
>> Blog: http://practicalid.blogspot.com
>> Photos: http://www.flickr.com/photos/gffphotos
> <OpenID Connect Registration - draft 20 - flattened.pdf>_______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab



More information about the Openid-specs-ab mailing list