[Openid-specs-ab] Ad-hoc conversation about i-names and OpenID Connect Migration 29-Aug-14

[Nat Sakimura]

Good point about my solution is that it is completely independent of
whatever the XRI providers does, unless they shut down the forwarding
service.

As long as the forwarding service is supported, I can specify
https://accounts.google.com as (+openid_iss) and I am done if google allows
external canonical ID to be mapped to its OpenID Connect ID. Of course, I
can set up id.sakimura.org and point (+openid_iss) to it as well.
If Fullxri decides to support OpenID Connect, then he can create a default
map for (+openid_iss) to its users.
Fullxri can make an independent decision on it. This kind of "distributed
governance" in fact is very much in-line with the original concept of user
centricity :-)

That's the beauty of this solution.

Nat


2014-09-04 0:13 GMT+09:00 John Bradley <ve7jtb at ve7jtb.com>:

> Markus indicated that Respect Networks is not planning on doing Connect.
>
> I don't think we have had input from them directly at this point.
>
> John B.
>
> On Sep 3, 2014, at 9:46 AM, Michael Schwartz <mike at gluu.org> wrote:
>
> > Nat,
> >
> > If Markus is ok with the changes, then I'm ok with it. Does it align
> with XRI as currently conceived by Respect Networks?
> >
> > - Mike
> >
> >
> >
> > -------------------------------------
> > Michael Schwartz
> > CEO Gluu
> >
> >
> >> Message: 2
> >> Date: Wed, 3 Sep 2014 12:39:23 +0900
> >> From: Nat Sakimura <n-sakimura at nri.co.jp>
> >> To: Mike Jones <Michael.Jones at microsoft.com>, Markus Sabadello
> >>      <markus.sabadello at gmail.com>
> >> Cc: "openid-specs-ab at lists.openid.net"
> >>      <openid-specs-ab at lists.openid.net>
> >> Subject: Re: [Openid-specs-ab] Ad-hoc conversation about i-names and
> >>      OpenID Connect Migration 29-Aug-14
> >> Message-ID: <20140903123923.24425e3f1a08a945e78af87a at nri.co.jp>
> >> Content-Type: text/plain; charset=US-ASCII
> >> 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
> > _______________________________________________
> > 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
>
>


-- 
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-ab/attachments/20140904/9842b362/attachment.html>