OpenID V.Next - Some Views to Consider

Sun May 16 21:41:27 UTC 2010

John,

Yes, that's what I'm suggesting.  The reason is simply to avoid making a lot
of changes in some of the basic parts of OpenID.

I understand the concern with multiple XML schemas and let's not forget,
too, that Yadis might not even be used and one might have to parse the HTML
document itself looking for headers.  I personally think that's unfortunate,
but it made sense for folks running blogs and who didn't have the ability to
insert Yadis headers or generate the required XML.  (I assume, anyway.
Whatever the case, there are a couple of places one must look for pointers
to the OP.

In any case, the world has clearly gotten beyond that and OpenID 2.0 is
reasonably-well supported.  Adding WebFinger does introduce another step,
but it's a generic service likely to be used for lots of things.  The
"discovery" issue that OpenID faces is one faced by lots of web services, so
it's an extra step I can live with.

Perhaps one thing we could do to help this process is put two values into
the Webfinger document:

1)      The claimed ID

2)      The URL to the OP endpoint

That would reduce the number of queries one needs to make, arms the OP with
all of the information that would it would normally have, and does cut out
the need to deal with either Yadis or digging through HTTP tags.  (Still,
the latter has to be kept to maintain backward compatibility and to support
those who don't have Webfinger and just enter their OpenID URI directly.)

Paul

From: John Bradley [mailto:john.bradley at wingaa.com] 
Sent: Saturday, May 15, 2010 8:36 AM
To: David Recordon
Cc: Paul E. Jones; openid-specs at lists.openid.net
Subject: Re: OpenID V.Next - Some Views to Consider

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
<mailto:acct%3Apaulej 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}
<http://www.packetizer.com/lrdd/?uri=%7Buri%7D> "

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 <mailto:acct%3Apaulej 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 <mailto:acct%3Apaulej 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
<mailto:acct%3Apaulej at packetizer.com> , then when WebFinger is employed, the
Subject of the XRD document is acct:paulej at packetizer.com
<mailto:acct%3Apaulej 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 <mailto:tag%3Auser 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 <http://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 <http://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/20100516/38df66a0/attachment-0001.htm>