OpenID V.Next - Some Views to Consider

Thu May 13 20:00:39 UTC 2010

For thirty years Internet users have understood their user identifier
to be username at domain.

I see absolutely zero interest from end users in being identified in
any other way. The attempts to provide them with this 'flexibility;
are unwanted and unnecessary. They are also counter-productive as they
mean that OpenID identifiers do not work with the legacy
infrastructure which expects a username at domain format. For example,
X.509 certificates and PGP key signing assertions.

I think we need to have a three part proposal for OpenID 3.0. Note
that this would not prevent support for legacy providers via OpenID
2.0 protocol.

1) The format of the identifier is 'user part' @ domain name. If the
user wants to assign roles etc they may do so according to existing
practice that has been established for email sub-addressing.

2) The resolution protocol for the domain part of the user identifier
is totally independent of any application protocol, including HTTP, it
uses DNS and only DNS to resolve the DNS name. This would be protocol
neutral and equally applicable to the OpenID protocol, Kerberos, SAML,
WS-Trust etc. etc.

3) One specific protocol option for resolving the 'user part'

The advantage of this approach is that parts 1 and 2 are completely
foundational, they may be applied by any authentication/identity
protocol, albeit possibly requiring a profile to be written to define
some additional details.

The only new mechanism is part 3 and that would be as far as possible
backwards compatible with OpenID 2.0.

The main consequences of this approach would be that

* Open ID 3.0 would effectively co-opt all past and future
authentication protocols into the OpenID space in precisely the same
way that the Web co-opted FTP, NNTP, WAIS etc. Even though the scope
of such services may be intentionally restricted to local scope, the
consistency means that we can leverage existing infrastructure for
internal purposes.

* OpenID 3.0 providers would be required to have network
administration privileges for their domain.

I see requiring network admin privileges for the domain to be
desirable. I really do not like the repurposing of the HTTP to be a
user profile management tool any more than I like repurposing the DNS
to be a user profile management tool. The approach of well known
addresses is deprecated with good reason and the proposed use is not
compatible with past precedent. The robots.txt file provides metadata
that relates to the site and the functioning of the Web server
publishing data. This proposal extends the function of the Web site to
making identity assertions, a very different issue.

On Thu, May 13, 2010 at 2:39 PM, John Bradley <john.bradley at wingaa.com> wrote:
> Paul,
> I am going to split my answer into two parts.
> The focus of this discussion needs to be on the charter of the Discovery WG
> and it;s scope.
> The specs list is a way for people to comment on the charter.   The work
> will be done on a separate mailing list subject to the OIDF IPR policy.
> We want the results of the spec process to be open and free of patent issues
> especially from the participants.
> People participating in the Discovery work will agree to contribute any IPR
> they hold with respect to the final output.
> Discussions on this list provide no IPR protection for the community.
> I think we have determined that we want the charter to allow exploring the
> inclusion of non http:  identifiers as input to the discovery process.
> An example of that would be the acct: URI used by webfinger.     That is
> consideration not a guaranteed inclusion,  this is only the charter scope.
> This discussion got onto the topic of allowing non http: URI as claimed ID.
>   Should the scope of the charter include considering that. as an option.
> I think some people have interpreted your comments as wanting the charter to
> restrict claimed_id to only http: scheme URI.
> I think Santosh and others want the WG to consider allowing that.
> If you are in agreement with allowing that in the scope of the WG charter
> then I think we can close that part of the discussion.
> That is only saying it can be considered not that it will be included in the
> final spec.
> The Second part of my answer is that you are close.
> Step 6 is a URI for the openID service not the users claimed_id as it has
> been discussed to my knowledge.
> That is part of what the WG needs to decide.
> That link will need a discovery step to get the parameters for the OP.
> There may be elements defined for the XRD that indicate what the localID or
> alias is at the OP and other overrides for delegation.
> That will be up to the Discovery WG to determine.
> Regards
> John B.
> On 2010-05-13, at 12:00 PM, Paul E. Jones 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
>
>

-- 
Website: http://hallambaker.com/