[Openid-specs-ab] Some comments on OpenID 2.0 to OpenID Connect Migration spec

Thu Aug 28 04:27:18 UTC 2014

I thought there was some plan to relaunch as cloud names.   Perhaps they are separate.  I expect Markus knows

Sent from my iPhone

> On Aug 27, 2014, at 11:24 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> 
> 2 are advertised at xri.org
> From: Nat Sakimura
> Sent: ‎8/‎27/‎2014 7:21 PM
> To: John Bradley
> Cc: Edmund Jay; Mike Jones; Markus Sabadello; openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Some comments on OpenID 2.0 to OpenID Connect Migration spec
> 
> So, how many I-Brokers are there now? 
> 
> =nat via iPhone
> 
> Aug 28, 2014 10:20、John Bradley <ve7jtb at ve7jtb.com> のメッセージ:
> 
>> In principal that is what we created the JRD for in the XRI WG. 
>> 
>> The question is more what NuStar is doing with the transition to cloud names and what roll Connect will have for whatever replaces iBrokers. 
>> 
>> Sent from my iPhone
>> 
>> On Aug 27, 2014, at 6:38 PM, Edmund Jay <ejay at mgi1.com> wrote:
>> 
>>> Shouldn't iss and sub contain values from the OpenID Connect provider? Unless, of course the OpenID Connect provider is https://xri.net
>>> 
>>> XRI resolution returns the OpenID 2.0 provider that is configured by the i-name owner.
>>> 
>>> So in regards to the spec, we need to determine whether it's possible to get the OpenID Connect iss from a GET request to https://xri.net/(some i-name) with an Accept header of application/json.
>>> 
>>> If not, then we need to think of another scheme for verification of XRI OpenID 2.0 Identifiers.
>>> 
>>> 
>>> 
>>> From: Mike Jones <Michael.Jones at microsoft.com>
>>> To: Markus Sabadello <markus.sabadello at gmail.com>; Nat Sakimura <sakimura at gmail.com> 
>>> Cc: "openid-specs-ab at lists.openid.net" <openid-specs-ab at lists.openid.net> 
>>> Sent: Wednesday, August 27, 2014 12:18 PM
>>> Subject: Re: [Openid-specs-ab] Some comments on OpenID 2.0 to OpenID Connect Migration spec
>>> 
>>> I suspect that the “iss” would be https://xri.net and the “sub” would be the i-number, such as “=!91F2.8153.F600.AE24”.
>>>  
>>> I guess the real question we haven’t explicitly asked is whether xri.net can/will become an OpenID Connect provider – which is what would make migration possible.  What are your thoughts on this, Markus?
>>>  
>>>                                                             -- Mike
>>>  
>>> 
>>> 
>>> From: Markus Sabadello [mailto:markus.sabadello at gmail.com] 
>>> Sent: Wednesday, August 27, 2014 11:50 AM
>>> To: Nat Sakimura
>>> Cc: Mike Jones; openid-specs-ab at lists.openid.net
>>> Subject: Re: [Openid-specs-ab] Some comments on OpenID 2.0 to OpenID Connect Migration spec
>>>  
>>> Yes to me it feels right to just say that openid2_id is the OpenID 2.0 Claimed Identifier.
>>> What I don't fully understand yet is whether in the OIDC world the Authorization Endpoint would be hosted 1. at https://xri.net/some/path, or 2. individually by the i-brokers.
>>> If 1., then for the migration spec I think no discovery step would be needed, since the issuer would always be https://xri.net anyway, no?
>>> What would the "iss" and "sub" fields be for an ID token issued for an XRI?
>>> 
>>> Markus
>>>  
>>> On Mon, Aug 25, 2014 at 6:25 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>>> Having said that, it is probably better to have the canonical XRI itself in the openid2_id. 
>>> Note though, Canonical ID only exists for XRI. In all other cases, it is the Verified Claimed ID. 
>>> In XRI's case, the value of the Canonical ID is used as the verified Claimed Identifier. 
>>> So, in general, just stating that openid2_id is OpenID 2.0 Identifier suffices. 
>>>  
>>> We would however have to add text to the discovery portion. 
>>>  
>>> In http(s) case, there is no change. 
>>> For XRI case, it has to be prefixed by https://xri.net/. 
>>>  
>>> My question to Markus at this point is how realistic that xri.net will implement this feature. 
>>> Do you have any idea? 
>>>  
>>> Nat
>>>  
>>> 2014-08-26 0:31 GMT+09:00 Nat Sakimura <sakimura at gmail.com>:
>>>  
>>> That would actually complicate 90% of the cases where openid2_id is a http(s) URI. 
>>> And I probably was a bit sleepy when I wrote the last response. 
>>> It is not xri://xri.net/ obviously. 
>>> I meant https://xri.net/ etc. so that the discovery process would be uniform to the RPs. 
>>>  
>>> 2014-08-25 23:44 GMT+09:00 Mike Jones <Michael.Jones at microsoft.com>:
>>>  
>>> I prefer the alternative that Markus is suggesting, in which we always use the OpenID 2.0 canonical identifier as the openid2_id claim value.  In fact, I would consider adding his example, in which this claim value is shown:
>>> "openid2_id": "=!91F2.8153.F600.AE24"
>>>  
>>> We should then describe how to prefix this value to perform discovery, rather than removing the prefix.
>>>  
>>>                                                             -- Mike
>>>  
>>> From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nat Sakimura
>>> Sent: Monday, August 25, 2014 7:26 AM
>>> To: Markus Sabadello
>>> Cc: openid-specs-ab at lists.openid.net
>>> Subject: Re: [Openid-specs-ab] Some comments on OpenID 2.0 to OpenID Connect Migration spec
>>>  
>>> Thanks Markus, 
>>>  
>>> I created tickets based on these comments. 
>>>  
>>> This particular one is: https://bitbucket.org/openid/connect/issue/950/migration-te-4-xri-portion-needs-change-by
>>>  
>>> For the relying party, I think it would be relatively straight forward to strip xri:// from openid2_id if they stored XRI as pure CanonicalID and causes less confusion than trying to figure out the type of openid2_id by sniffing if it starts from "=" or "!" or "@" etc. 
>>>  
>>> This comment thus seem to imply that we should add some text in section 7, e.g., adding: 
>>>  
>>> If the OpenID 2.0 Identifier starts with xri://xri.net/ then the relying party MUST extract the Canonical XRI by stripping "xri://xri.net/" from the beginning of the OpenID 2.0 Identifier. 
>>>  
>>> What do you think? 
>>>  
>>> Nat
>>>  
>>> 2014-08-23 21:36 GMT+09:00 Markus Sabadello <markus.sabadello at gmail.com>:
>>> In section 4:
>>> "For XRI, OpenID 2.0 Identifier MUST be created as https://xri.net/ concatenated with the user’s verified XRI without the xri:// scheme. "
>>> The problem with this I think is that in OpenID 2.0, for an XRI the Claimed Identifier is the pure CanonicalID (I-Number), without https:// or xri:// scheme. For example, an RP might have =!91F2.8153.F600.AE24 as the Claimed Identifier (openid2_id) for a user in its database.
>>> So I think in section 4, we should either not say anything specific at all about XRI, or say something like this:
>>> 
>>> "For XRI, OpenID 2.0 Identifier MUST be the content of the <CanonicalID> element, as specified in [OpenID.2.0]"
>>> Then an example ID Token would be:
>>> {
>>>  "iss": "?? not sure",
>>>  "sub": "?? not sure",
>>>  "aud": "s6BhdRkqt3",
>>>  "nonce": "n-0S6_WzA2Mj",
>>>  "exp": 1311281970,
>>>  "iat": 1311280970,
>>>  "openid2_id": "=!91F2.8153.F600.AE24"
>>> }
>>> But then I can see that obtaining an "iss" as described in sections 2 and 6 won't work.
>>> 
>>> 
>>> 
>>>  
>>> -- 
>>> Nat Sakimura (=nat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>> 
>>> 
>>>  
>>> -- 
>>> Nat Sakimura (=nat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>> 
>>> 
>>>  
>>> -- 
>>> Nat Sakimura (=nat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>>  
>>> 
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140828/7244ef22/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2734 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140828/7244ef22/attachment.p7s>