[Openid-specs-ab] Review Comments on Discovery

Nat Sakimura sakimura at gmail.com
Thu Nov 7 17:41:53 UTC 2013


Mike -

If Torsten agrees to the Proposed DoC, shall I apply the edit to the XML
since you have boat road of edits to toher documents including JOSE and
OAuth WG stuff?

Torsten,

Is the PDoC agreeable?


2013/11/7 Nat Sakimura <sakimura at gmail.com>

> Proposed DoC (Disposition of Comment)
>
>
> 2013/11/6 Torsten Lodderstedt <torsten at lodderstedt.net>
>
>> Hi Mike,
>>
>> here are my comments (some of them have already been discussed during the
>> meeting on Sunday). Note: For your convenience, I also attached the word
>> file containing my comments.
>>
>> regards,
>> Torsten.
>>
>> -----
>>
>> Sections 2 & 4 describe a discovery process composed of three (mostly
>> optional) steps (issuer discovery, create config URI, retrieve config
>> data). I think it would be helpful to describe the whole process first,
>> before diving into the details. This would support the reader to get
>> guidance and allow to point out optional and mandatory parts of this spec.
>>
>> section 2 heading - [already discussed] Isn’t this section about the
>> discovery of the OP’s issuer URI? This should be spelled out. I got screwed
>> since I thought the URI discovered here is directly used to retrieve config
>> data. I may not be the only one.
>>
>> 2.1.1.
>>
>> 1. step - Why is XRI mention given all input must be a URI? I thought
>> XRIs are a super-set of URIs.
>>
>
> Reject.
> XRI defines particular shortcut syntax. We are special casing it here to
> ease the transition from OpenID 2.0.
>
>
>>
>> 2. step - Seems the URI must always contain an authority component? I
>> think this should be stated explicitly.
>>
>
> Accept in principle.
> Exact text needed.
>
>
>>
>> 2.1.2
>>
>> This is stuff is hard to read and understand. Some example strings would
>> be helpful for the reader. This would also lay a bridge to the next section.
>>
>> Accept in principle.
> Exact text needed.
>
>
>> "A string of any other type" - What ist he other type you refer to? Any
>> other than a URI?
>>
>
> Accept in principle.
> Perehaps rephrase it as
> "A string not starting with =, @, !"
>
>
>>
>> "2. If the userinfo component is present " - What about the host?
>>
>
> Accept in principle.
> Add note explaining that for userinfo component is to be present, host
> component has to be present.
>
> As a separate note, perhaps we should align the language "portion" and
> "component" as well as the order of the appearance in this paragraph.
>
>
>>
>> 3.
>>
>> "issuer" - Is this value required to be the same as the issuer URI
>> (possibly) discovered by the process described in section 2? [already
>> discussed, yes]
>>
>
> Noted.
>
>
>>
>> "authorization_endpoint
>> OPTIONAL. URL of the OP's Authentication and Authorization Endpoint" -
>> This endpoint is also the OAuth 2.0 authz endpoint, this should be
>> mentioned (as for the following parameter).
>>
>
> Accept in principle.
> Add NOTE:.
>
>
>>
>> "userinfo_endpoint"
>> "This URL MUST use the https scheme and MAY contain port, path, and query
>> parameter components. " - I think this particular normative text should be
>> given in the core, only. Otherwise we end up with normative text regarding
>> a certain concept spread/copied over the OIDC document suite, which makes
>> maintaining consistence more difficult.
>>
>
> Accept in principle.
> Drop the second sentence. If the same does not appear in the Core, add
> them to the Core.
>
>
>>
>> "scopes_supported
>> ... The server MUST support the openid scope value. " - See above, this
>> is not about discovery. I think it should at most be a note, but I would
>> prefer a reference to the respective section in core.
>>
>
> Accept in principle.
> Make it a NOTE as this is rather important to bring it up.
>
>
>>
>> "response_types_supported
>> ... Dynamic OpenID Providers MUST support the code, id_token, and the
>> token id_token response type values." - Same here, could refer to the MTI
>> section in core.
>>
>
> Accept.
>
>
>>
>> grant_types_supported
>> ... Dynamic OpenID Providers MUST support the authorization_code and
>> implicit grant type values and MAY support the urn:ietf:params:oauth:grant-type:jwt-bearer
>> grant type defined in JSON Web Token (JWT) Profile for OAuth 2.0 Client
>> Authentication and Authorization Grants [OAuth.JWT]." - Same here.
>> Moreover, I’m surprised this text mentions the JWT Bearer token profile.
>> This is not even mentioned in core. What is the rationale?
>>
>
> Accept in principle.
> Just refer the core.
>
>
>>
>> "subject_types_supported
>> ... Valid types include pairwise and public." - Are there other types
>> envisioned?
>>
>
> Noted.
> We are not precluding the possibilities.
>
>
>>
>> "... The algorithm RS256 MUST be included. The value none MAY be
>> supported, but MUST only be used with the Authorization Code Flow." -
>> Normative text on non-discovery aspects again. I would suggest to make it a
>> note or a reference instead.
>>
>
> Accept in principle.
> Just reference Core as a normative text.
> Add NOTE that RS256 is required by the Core avoiding normative language.
>
>
>>
>> "request_object_encryption_alg_values_supported
>> ... Authorization Server ..." - I would suggest to call it “OP”
>> consistently.
>>
>
> Accept.
> Replace Authorization Server with OP.
>
>
>>
>> "token_endpoint_auth_methods_supported
>> OPTIONAL. JSON array containing a list of authentication methods
>> supported by this Token Endpoint. The options are client_secret_post,
>> client_secret_basic, client_secret_jwt, and private_key_jwt, ... " - Same
>> here about normative text
>>
>
> Accept in principle.
>
>
>>
>> "request_uri_parameter_supported
>> OPTIONAL. Boolean value specifying whether the OP supports use of the
>> request_uri parameter, with true indicating support. If omitted, the
>> default value is true. " - I’m wondering why the default is different for
>> request object and reference. I would expect false for both of them.
>>
>
> Discuss.
> The hisotrical reason is that request_uri  used to be in MTI.
> Need to check if it is true still.
>
>
>> 4.
>>
>> "This step is OPTIONAL. The OpenID Provider endpoints and configuration
>> information MAY be obtained out-of-band." - I’m wondering why this is
>> optional as I consider this the main part of discovery. Or does it refer to
>> derivation of the config URI based on the issuer URI? Then I would suggest
>> to change section heading to something like “Deriving OpenID Provider
>> Config URI”. This might also require to push 4.1. to the top level.
>>
>
> Reject.
> All the information obtained in this section may be obtained oob and not
> using discovery at all. However, it would be good to explain a little more
> about it.
>
>
>>
>> ".. Providers supporting discovery MUST support receiving WebFinger
>> requests via TLS" - Is this statement misplaced. As it refers to WebFinger,
>> it might belong to section 2?
>>
>
>  Accept.
> Move to section 2.
>
>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131107/3dcd12f6/attachment.html>


More information about the Openid-specs-ab mailing list