Re: Review of Proposed Implementer’s Draft of OpenID 2.0 to OpenID Connect Migration Specification

Thu Oct 2 08:08:13 UTC 2014

Changes are committed to bitbucket.

2014-09-25 1:11 GMT+09:00 Mike Jones <Michael.Jones at microsoft.com>:

>  If it’s all non-normative, go ahead and make the proposed changes and
> post them to bitbucket.  After the WG has a chance to review them for a few
> days, I’ll update the draft at openid.net/specs and post a note about the
> update.
>
>
>
> *From:* Nat Sakimura [mailto:sakimura at gmail.com]
> *Sent:* Wednesday, September 24, 2014 6:49 AM
> *To:* Torsten Lodderstedt
> *Cc:* Mike Jones; specs at lists.openid.net
> *Subject:* Re: Review of Proposed Implementer’s Draft of OpenID 2.0 to
> OpenID Connect Migration Specification
>
>
>
> Thanks Torsten:
>
>
>
> Here are my reply inline.
>
>
>
> 2014-09-22 1:37 GMT+09:00 Torsten Lodderstedt <torsten at lodderstedt.net>:
>
> Hi Mike,
>
> here are my review comments:
>
> section 2
>
> PPID and openid2_realm:
> "If PPID was used to obtain the OpenID 2.0 Identifier" - How is the RP
> supposed to know/find out whether the OP issued a PPID or a
> universal/global OpenID? I would rather suggest to make this a mandatory
> parameter, the RP must know its OpenID 2.0 realm anyway.
>
>
>
> Amiable to it. It inherited (OPTIONAL) from OpenID 2.0 where it was
> optional as long as openid.return_to was given. From the point of view of
> locking down the IPR, I think it does not matter though so we can wait to
> fix it till after the implementer's draft.
>
>
>
>
> "If the value of openid2_id is an XRI [XRI_Syntax_2.0], the mechanism for
> verifying the iss in the ID Token is still TBD" - Do you want to determine
> this before the spec is published? If not I would suggest to replace the
> TBD by "... is out of scope for this specification."
>
>
>
> This is a bug. It is now fully specified, but I failed to remove the note
> somehow. As this is just a non-normative NOTE:, it can wait till after the
> Implementer's draft vote for the fix, IMHO.
>
>
>
>
>
>
> "There could be an attack by a malicious RP to obtain the user’s PPID for
> another RP to perform identity correlation. To mitigate the risk, the OP
> MUST verify that the realm and RP’s Redirect URI matches as per Section 9.2
> of OpenID 2.0 [OpenID.2.0]."
>
> section 3
>
> I'm not sure what this means. Does it mean the RP's XRDS document must
> contain the RP’s Redirect URI (a OAuth/OIDC redirect_uri)? If so, is the RP
> supposed to use a certain service Type or
> "http://specs.openid.net/auth/2.0/return_to"
> <http://specs.openid.net/auth/2.0/return_to>?
>
> Example:
> <Service xmlns="xri://$xrd*($v*2.0)">
>   <Type>http://specs.openid.net/auth/2.0/return_to</Type>
>   <URI>http://consumer.example.com/return</URI>
> </Service>
>
>
>
> It just means that openid2_realm MUST be (roughly) a substring of OpenID
> Connect/OAuth's Redirect URI. No XRDS is involved. Exact rule of the
> matching is given in Section 9.2 of OpenID 2.0.
>
>
>
>
> section 4.1.2
>
> "If a corresponding OpenID 2.0 Identifier is not found for the
> authenticated user, the openid2_id claim in the ID Token MUST have the
> value NOT FOUND." I assume the value must be "NOT FOUND"?
>
>
>
> Yes. It is going to be a verbatim string "NOT FOUND".
>
>
>
>
> section 6
>
> step 2
> "... The server SHOULD return a JSON with iss ..." Why not MUST? Otherwise
> the RP cannot verify whether the OP OP is Authoritative.
>
>
>
> The request is one of the factor for the server to decide to return the
> positive response.
>
> It may decide not to return anything for some reason, e.g., security
> doubt, and to allow this behavior, the normative text is written in SHOULD
> and not MUST.
>
>
>
>
> step 3
> "If the openid2_id does not start with http or https, it is an XRI
> [XRI_Syntax_2.0]. In this case, the RP needs to construct the verification
> URI by concatenating https://xri.net/, the value of the openid2_id claim,
> and /(+openid_iss). Requesting the resulting URI with GET will result in a
> series of HTTP 302 redirects. The RP MUST follow the redirects until HTTP
> status code 200 OK comes back. The URI that resulted in 200 OK is the
> authoritative issuer for the XRI. This URI MUST exactly match the iss in
> the ID Token except for the potential trailing slash (/) character."
>
> Doesn't this contradict the note regarding XRI in section 2 (TBD)?
>
>
>
> Right. This was the last section that I wrote, and I forgot to remove the
> TBD note.
>
> Sorry about that. The TBD NOTE shall go away.
>
>
>
>
> section 8.1
>
> "This standard allows the RP to verify the authenticity of the OpenID 2.0
> Identifier through ID Token even after the OpenID 2.0 OP is taken down. To
> enable this, the OP MUST publish the public keys that were used to sign the
> ID Token with openid2_id claim at the URI that this OpenID 2.0 Identifier
> points to."
>
> Where is the relation between the openid2 identifier and the OP's public
> keys?  Public keys are nowhere else mentioned in this spec.
>
>
>
> This is another bug. While the text is non-normative, it would have been
> really good to spot it before going to the public review. This is a
> historic text which is not relevant anymore. The second sentence should be
> deleted.
>
>
>
> To Mike (as the secretary of OIDF):
>
>
>
> All of the above is editorial. No normative text would be touched.
>
> Is it appropriate to amend them during or after the public review period
> before the vote?
>
>
>
> Nat
>
>
>
>
> best regards,
> Torsten.
>
> Am 17.09.2014 03:10, schrieb Mike Jones:
>
>   The OpenID Connect Working Group recommends approval of the following
> specification as an OpenID Implementer’s Draft:
>
> ·         OpenID 2.0 to OpenID Connect Migration 1.0
> <http://openid.net/specs/openid-connect-migration-1_0-06.html> – Defines
> how to migrate from OpenID 2.0 to OpenID Connect
>
>
>
> An Implementer’s Draft is a stable version of a specification providing
> intellectual property protections to implementers of the specification.
> This note starts the 45 day public review period for the specification
> drafts in accordance with the OpenID Foundation IPR policies and
> procedures.  This review period will end on Friday, October 31, 2014.
> Unless issues are identified during the review that the working group
> believes must be addressed by revising the drafts, this review period will
> be followed by a seven day voting period during which OpenID Foundation
> members will vote on whether to approve these drafts as OpenID
> Implementer’s Drafts. For the convenience of members, voting may begin up
> to two weeks before October 31st, with the voting period still ending on
> Friday, November 7, 2014.
>
>
>
> This specification is available at:
>
> ·         http://openid.net/specs/openid-connect-migration-1_0-06.html
>
>
>
> A description of OpenID Connect can be found at http://openid.net/connect/.
> The working group page is http://openid.net/wg/connect/.  Information on
> joining the OpenID Foundation can be found at
> https://openid.net/foundation/members/registration.  If you’re not a
> current OpenID Foundation member, please consider joining to participate in
> the approval vote.
>
>
>
> You can send feedback on the specifications in a way that enables the
> working group to act upon your feedback by (1) signing the contribution
> agreement at http://openid.net/intellectual-property/ to join the working
> group (please specify that you are joining the “AB+Connect” working group
> on your contribution agreement), (2) joining the working group mailing list
> at http://lists.openid.net/mailman/listinfo/openid-specs-ab, and (3)
> sending your feedback to the list.
>
>
>
> -- Michael B. Jones – OpenID Foundation Board Secretary
>
>
>
> (This notice has also been posted at
> http://openid.net/2014/09/16/review-of-proposed-implementers-draft-of-openid-2-0-to-openid-connect-migration-specification/
> .)
>
>
>
>
>
> _______________________________________________
>
> specs mailing list
>
> specs at lists.openid.net
>
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>
>
>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>
>
>
>
> --
> 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/attachments/20141002/6451e181/attachment.html>