[Openid-specs-ab] Ad-hoc conversation about i-names and OpenID Connect Migration 29-Aug-14
Nat Sakimura
n-sakimura at nri.co.jp
Wed Sep 3 03:39:23 UTC 2014
For what is worth,unlike I had hoped for, XRI would need a special casing.
Also, whether xri.net would support this spec is unclear.
Best compromise that I can think of right now is to use the forwarding service of XRI.
Forwarding service is a service that XRI providers needs to implement.
You can create a node under your XRI to point to another location.
For example, I can define
=nat/(+contact)
to forward it to a contact page of my choice.
Similarly, I could create
=nat/(+openid_iss)
and map it to any page.
For example, if my OpenID Connect issuer is https://example.com/
then I can define =nat/(+openid_iss) to map to https://example.com/.
It works this way.
1) The client sends request to https://xri.net/=nat/(+openid_iss).
2) The host xri.net responds with 302 redirect to for example,
http://forwarding.fullxri.com/forwading/=nat/(+openid_iss)
3) The client send request to it.
4) The host replies with 302 redirect to
https://example.com/
5) The client requests https://example.com/.
6) The page returns 200 OK so the redirection sequence terminates here.
7) Now the client has found that https://example.com/ is the
authoritative OpenID Connect issuer.
8) Match it to the value of "iss" in the ID Token.
This should work with any XRI provider without xri.net doing something.
Thoughts?
Nat
On Fri, 29 Aug 2014 15:55:57 +0000
Mike Jones <Michael.Jones at microsoft.com> wrote:
> Ad-hoc conversation about i-names and OpenID Connect Migration
> 29-Aug-14
>
> Nat Sakimura
> Mike Jones
> Markus Sabadello
> John Bradley
> Nov Matake
> Edmund Jay
>
> There are three xri registrars now:
> fullxri - Markus
> 1id - In Australia
> Respect Network - Drummond Reed, etc.
> Respect Network has a number of
> resellers
>
> i-names are now called cloud names
> The main company developing services on top of cloud names is Respect
> Network
>
> They plan to replace the @ symbol for business names with +
>
> Mike asked whether some of the providers are going to be supporting
> OpenID Connect Markus finds is personally interesting in doing
> something to make xri compatible with OpenID Connect
>
> The original i-services are not supported by Respect Network
> OpenID 2.0
> Contact page
> Respect Network has implemented an xri-based "Respect Connect"
> protocol
>
> John: Without xri.net running an OpenID Connect provider, migration
> could only happen for specific i-brokers
>
> It's not clear whether the right thing to do would be for xri.net to
> be the issuer or for the i-broker
>
> We believe that we can't ask Connect RPs to do anything special for
> i-names Ideally, you would type xri.net into discovery
> Or you could type fullxri.com
> The "sub" claim could just be the i-number
> The "iss" could be fullxri.com or another i-broker
>
> Mike: For the Migration spec, we should say that the mechanisms for
> migrating i-names are still under discussion
>
> Nat: We could allow the provider to return URLs like
> https://fullxri.com/<i-number> as the openid2_id claim Mike: This
> wouldn't match the name in the database, which is the i-number John:
> The openid2_id claim should be the claimed identifier
>
> John: The RP could do XRI resolution on the claimed identifier to
> discover the actual provider The OpenID Connect service could be
> added to the XRD This can be done by i-brokers without support from
> xri.net John believes that people aren't likely to modify their XRI
> libraries to do any of this He believes that some kind of manual
> account linking to be the only practical approach
>
> Resolution: We should go to an implementer's draft saying that the
> openid2_id claim will be the verified identifier and that the
> mechanism for discovering the right provider is still TBD This
> mechanism could involve work by xri.net or by the i-brokers
>
> Open Issues:
> #949 Migration - (te) 2., and 6. verification rule (by
> #Markus)
> Nat will fix with won't fix
> #950 Migration - (te) 4. xri portion needs change (by
> #Markus)
> Accepted - see "Resolution" above
> #955 - Migration - (ge) xri.net support of the
> #Migration spec
> Dup of 950
> #956 - Migration - (te) openid.identity support? (by
> #Nov)
> We don't want to get into trying to
> define workarounds for OpenID 2.0 bugs Providers violating the OpenID
> 2.0 spec could similarly violate the migration spec to make things
> work Nat will add an implementer's note about extracting the fragment
> in this case
>
More information about the Openid-specs-ab
mailing list