[Openid-specs-ab] Review Comments on Discovery

Nat Sakimura sakimura at gmail.com
Thu Nov 7 15:57:53 UTC 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131107/b22bd19b/attachment.html>


More information about the Openid-specs-ab mailing list