Changes are committed to bitbucket. 2014-09-25 1:11 GMT+09:00 Mike Jones <[email protected]>:
> 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:[email protected]] > *Sent:* Wednesday, September 24, 2014 6:49 AM > *To:* Torsten Lodderstedt > *Cc:* Mike Jones; [email protected] > *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 <[email protected]>: > > 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 > > [email protected] > > http://lists.openid.net/mailman/listinfo/openid-specs > > > > > _______________________________________________ > specs mailing list > [email protected] > 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
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
