The updated version has been posted at
http://openid.net/specs/openid-connect-migration-1_0-06.html. The original
version is posted at
http://openid.net/specs/openid-connect-migration-1_0-06_orig.html to facilitate
comparison. An update notice was also added to the end of the review notice
posting at
http://openid.net/2014/09/16/review-of-proposed-implementers-draft-of-openid-2-0-to-openid-connect-migration-specification/.
-- Michael B. Jones – OpenID Foundation Board
Secretary
From: Nat Sakimura [mailto:[email protected]]
Sent: Thursday, October 02, 2014 1:08 AM
To: Mike Jones
Cc: Torsten Lodderstedt; [email protected]
Subject: Re: Review of Proposed Implementer’s Draft of OpenID 2.0 to OpenID
Connect Migration Specification
Changes are committed to bitbucket.
2014-09-25 1:11 GMT+09:00 Mike Jones
<[email protected]<mailto:[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<http://openid.net/specs> and post a note
about the update.
From: Nat Sakimura [mailto:[email protected]<mailto:[email protected]>]
Sent: Wednesday, September 24, 2014 6:49 AM
To: Torsten Lodderstedt
Cc: Mike Jones; [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
[email protected]<mailto:[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
