OpenID V.Next - Some Views to Consider

Sat May 15 12:36:20 UTC 2010

David,

If I understand Paul correctly he is asking for a two stage resolution.

Stage 1 Webfinger to get a openID identifier for the person.
Stage 2 Current Yadis resolution on that ID to get the endpoint.

That is why he prefers claimed ID to remain http: URI.

This would require 3 or 4 GET to go from input identifier acct:foo at bar.com to a openID endpoint the RP can query.

It also requires the RP to parse the current XRDS XML and the new XRD XML with different schema and semantics.

I think he and some others are looking at this as webfinger being a separate front end to existing openID 2.0 authentication.

Paul correct me if I have that wrong.

John B.

On 2010-05-15, at 1:16 AM, David Recordon wrote:

> Hey Paul,
> That sounds right. I'd really like to see us simplify it though. Ideally getting to where a RP can make a single HTTP request and end up with the OpenID endpoint. For example, why not combine steps #3 and #4?
> 
> --David
> 
> 
> On Thu, May 13, 2010 at 9:00 AM, Paul E. Jones <paulej at packetizer.com> wrote:
> John,
> 
>  
> Perhaps we need to walk through this so that I don’t get confused.
> 
>  
> I had assumed it would work this way:
> 
>  
> 1) I enter paulej at packetizer.com into the RP’s login window
> 
> 2) The RP would assume this is acct:paulej at packetizer.com
> 
> 3) The RP would query http://www.packetizer.com/.well-known/host-meta to get an XRD document that contains an lrdd link relation with, for example, an href="http://www.packetizer.com/lrdd/?uri={uri}"
> 
> 4) The RP would then query the LRDD link with the acct: URI
> 
> 5) The would return another XRD document with a <Subject> of acct:paulej at packetizer.com, and a <Link> with a link relation value of “openid” (or whatever the group wants to define)
> 
> 6) The href associated with the above <Link> would be the user’s claimed ID.
> 
>  
> At this point, the RP has an OpenID claimed ID, just as if the user had entered that value into the current OpenID login box to begin with.
> 
>  
> BTW, all of this is functioning on my site now if you want to actually issue queries to see the results.  It’s not being used for anything right now, but I implemented it just for the heck of it :-)
> 
>  
> So, if you’re suggesting the mapping from paulej at packetizer.com to claimed ID would work differently, what steps are you proposing to be taken?
> 
>  
> Paul
> 
>  
> From: John Bradley [mailto:john.bradley at wingaa.com] 
> Sent: Thursday, May 13, 2010 11:25 AM
> To: Paul E. Jones
> Cc: 'Santosh Rajan'; openid-specs at lists.openid.net
> 
> 
> Subject: Re: OpenID V.Next - Some Views to Consider
> 
>  
> The openID link relation is to your openID service eg Google not your claimed_id.
> 
>  
> The <Subject> of the XRD is the name of the thing you are looking up.
> 
>  
> If you input paulej at packetizer.com into a LRDD resolution process and use webfinger for normalization you will get a XRD.
> 
>  
> That XRD may have the <Subject>  http://openid.packetizer.com/paulej 
> 
>  
> That would be up to you or your OP to decide.  
> 
>  
> I think Santosh wants to allow you the option of having acct:paulej at packetizer.com as the subject of the XRD.
> 
>  
> This leads to questions about what the core protocol is validating.  Is it the claimed_id or the openid.identity.  
> 
> Do we need both,  is delegation supported, and if so how, etc.
> 
>  
> I think the WG needs to consider what impact having non http/https URI as claimed ID has on the overall protocol.
> 
>  
> I don't want to restrict the WG from considering the issue via the charter.
> 
>  
> John B.
> 
> On 2010-05-13, at 10:51 AM, Paul E. Jones wrote:
> 
> 
> 
> Santosh,
> 
>  
> The subject of paulej at packetizer.com is what?
> 
> If that can be assumed to be acct:paulej at packetizer.com, then when WebFinger is employed, the Subject of the XRD document is acct:paulej at packetizer.com.  That’s not what I want.
> 
>  
> Inside the XRD document should be a link like this:
> 
> <Link rel="openid" href="http://openid.packetizer.com/paulej"/>
> 
>  
> The link relation value is still subject to debate, but that’s what I think we should use to identify the claimed ID.
> 
>  
> Paul
> 
>  
>  
> From: openid-specs-bounces at lists.openid.net [mailto:openid-specs-bounces at lists.openid.net] On Behalf Of Santosh Rajan
> Sent: Thursday, May 13, 2010 1:50 AM
> To: John Bradley
> Cc: openid-specs at lists.openid.net
> Subject: Re: OpenID V.Next - Some Views to Consider
> 
>  
> I will vote for the Subject of the XRD to be the claimed_id. It only seems natural, and clean to do that. 
> 
> On Thu, May 13, 2010 at 3:17 AM, John Bradley <john.bradley at wingaa.com> wrote:
> 
>  
> So if openID supports LRDD then normalization rules for Acct: and other URI schemes could be specified so that they to can be resolved to a XRD.
> 
>  
> The question will be for the core protocol what to use as the claimed_id.   
> 
>  
> There are three schools of thought.
> 
> 1 The normalized input identifier
> 
> 2 The Subject of the XRD
> 
> 3 The claimed_id that the OP returns.
> 
>  
> There are arguments to be made for all three.
> 
>  
> I expect this to be addressed in the WG.
> 
>  
>  
> On 2010-05-12, at 12:34 PM, Santosh Rajan wrote:
> 
>  
> Starting a new thread here based on an earlier one quoted below.
> 
>  
> Let us reconsider the definition of OpenID for V.next. I would like to see a new definition for OpenID.
> 
>  
> "An OpenID is Any Valid URI that can be resolved to it's Descriptor".
> 
>  
> Now let me give a little explanation on the above, with a few points.
> 
> 1) Existing OpenID's version 1 and 2 are compatible with the above definition. (http(s) OpenId's version 1 and 2 do resolve to their descriptor's)
> 
> 2) Email like identifiers are compatible with the above definition with the webfinger protocol, and ofcourse resolve to their descriptor's.
> 
>  
> Now any other future protocol that can make its URI resolvable to a descriptor, will also be a Valid OpenID. Let me give an example.
> 
>  
> According to the above definition we can make "tag URI's" valid OpenID's, as long as we have a protocol to resolve this URI to its's descriptor.
> 
>  
> tag:user at example.com,2007-11-02:Tag_URI
>  
> Now as far as I am concerned tag URI's are even better as OpenID's, because they are unique over space and time.
> 
>  
> Webfinger support for tag URI's anyone? :-)
> 
>  
> ---------- Forwarded message ----------
> From: Paul E. Jones <paulej at packetizer.com>
> Date: Wed, May 12, 2010 at 8:11 AM
> Subject: RE: Draft charter for v.Next Attributes working group
> To: Santosh Rajan <santrajan at gmail.com>
> Cc: Mike Jones <Michael.Jones at microsoft.com>, jsmarr at stanfordalumni.org, openid-specs at lists.openid.net, tech-comm at openid.net
> 
> 
> Santosh,
> 
>  
> Why not store the claimed ID in the webfinger (LRDD) XRD document?
> 
>  
> The objective, I would hope, is to make it easier to log into web sites.  Email-style identifiers make that easier, but the system does not have to be built around those.
> 
>  
> So, I sign up with a service provider.  Let’s just use my own site as an example.  I am assigned an email address paulej at packetizer.com.  Behind the scenes, I am also assign an OpenID ID http://openid.packetizer.com/paulej.  Now, when I visit a web site, I can type ‘paulej at packetizer.com’ and the site can perform a webfinger query to discovery by OpenID ID.  We would define a link relation (something we’ve talked about before) that represents openid.  It could be http://openid.net/identity or it could be simply “openid” (since link relations need not be URIs).  Looking at the href of the “openid” link relation, one would find my OpenID URIhttp://openid.packetizer.com/paulej.
> 
>  
> Now, should I wish to have a different email provider than my openid provider, that’s fine: I could change the record associated with the openid link relation to contain a different OpenID identifier.  Alternatively, I could just get an account at someopenidop.com and they might assign an e-mail style address like paulej at someopenidop.com and perform the Webfinger resolution behind the scenes.
> 
>  
> Anyway, issue this request:
> 
> $ curl http://www.packetizer.com/lrdd/?uri=acct:paulej@packetizer.com
> 
>  
> You’ll see the link relation for my claimed ID:
> 
> <Link rel="http://openid.net/identity"
> 
>       href="http://openid.packetizer.com/paulej"/>
> 
>  
> It does introduce another protocol, but I think these play nicely together.  The real identity would remain the URL that OpenID uses today.  The email identifier would just be an alias for it.
> 
>  
> Paul
> 
>  
> From: Santosh Rajan [mailto:santrajan at gmail.com] 
> Sent: Tuesday, May 11, 2010 12:39 PM
> To: Paul E. Jones
> Cc: Mike Jones; jsmarr at stanfordalumni.org; openid-specs at lists.openid.net; tech-comm at openid.net
> Subject: Re: Draft charter for v.Next Attributes working group
> 
>  
>  
> On Tue, May 11, 2010 at 8:55 AM, Paul E. Jones <paulej at packetizer.com> wrote:
> 
>  
> Adding support for email-style addresses is something I like, but something that can be provided via webfinger.  Thus, no change to the base protocol.
> 
>  
>  
> I beg to disagree here. I think the base protocol needs to address the issue of email like identifiers. I would like to see that email like identifiers are valid OpenID claimed id's.
> 
> So something like acct:example @ example.com should be a valid OpenID claimed_id.
> 
>  
> Also this discussion should not be in this thread (about attributes) and maybe someone could start a new thread on this subject.
> 
>  
> Thanks
> 
> Santosh
> 
>  
>  
> http://hi.im/santosh
> 
> 
> 
> 
> -- 
> http://hi.im/santosh
> 
> 
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
> 
>  
> 
> 
> 
> -- 
> http://hi.im/santosh
> 
> 
>  
> 
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100515/079a053d/attachment.htm>