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

Wed Sep 24 16:11:42 UTC 2014

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<mailto: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<mailto:specs at lists.openid.net>

http://lists.openid.net/mailman/listinfo/openid-specs

_______________________________________________
specs mailing list
specs at lists.openid.net<mailto: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/dcee8be5/attachment.html>