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

Nat Sakimura sakimura at gmail.com
Wed Sep 24 13:49:03 UTC 2014


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 listspecs at lists.openid.nethttp://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20140924/b9b94b29/attachment.html>


More information about the specs mailing list