[Openid-specs-ab] Review Comments on Discovery

Nat Sakimura sakimura at gmail.com
Thu Nov 7 18:31:32 UTC 2013


*Mike*:

OK. As long as you can do it reasonably quickly, I am fine. Much better to
have a single person editing at this stage.

*For the WG: *

If you do not agree to the proposed DoC, you need to respond quickly now,
within a day or two.


2013/11/7 Mike Jones <Michael.Jones at microsoft.com>

>  Please do not edit any of the sources.  The working group has not had
> time to review any of this.  I know that I haven’t.
>
>
>
> *From:* Nat Sakimura [mailto:sakimura at gmail.com]
> *Sent:* Thursday, November 07, 2013 9:42 AM
> *To:* Torsten Lodderstedt
> *Cc:* Openid-specs Ab; Mike Jones
> *Subject:* Re: [Openid-specs-ab] Review Comments on Discovery
>
>
>
> 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
>



-- 
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/95ba84ef/attachment-0001.html>


More information about the Openid-specs-ab mailing list