Draft OpenID v.Next Discovery working group charter

Phillip Hallam-Baker hallam at gmail.com
Thu Apr 15 20:12:35 UTC 2010


I think we are actually getting to some useful stuff here.

On Thu, Apr 15, 2010 at 2:56 PM, Paul E. Jones <paulej at packetizer.com> wrote:
> Phillip,
>
>> It may be that we want to support Webfinger. But I disagree with the
>> example given.
>
> What example did I give? :-)  I just cast my vote for Webfinger over SRV.

The example use case is not one I find persuasive, or rather I think
it is one which
has to be considered in greater depth.

>> In general as far as the charter goes, I think that it needs to have a
>> statement to the effect that the WG will liaise with the IETF and W3C
>> groups to arrive at a consistent architecture.
>
> In my experience, liaising with the IETF is somewhat useless.  It's an
> organization that does not work that way.  It would be better to have folks
> working on OpenID engage in the IETF, because that's how stuff gets done.
> Perhaps that's what you mean, but sending a formal liaison statement does
> not always get consideration and response.

There are ways of working with the IETF that work and others that do
not. In particular it is a feature of every standards body that none
of them has ever really taken on board the fact that they need to
interact with standards organizations that have come into being after
they emerged. IETF still pretty much acts as if W3C did not exist and
was an entirely illegitimate usurper. W3C behaves the same way to
OASIS.

That is one reason why I did not support the creation of yet another
standards body for OpenID. IETF is not a fast process, but this
process has put us three years behind where we might have been going
through an existing body.


> Alice could report either and Webfinger could be used at either.
> Personally, I prefer using my own domain, as I can configure webfinger on it
> to point to whatever IDP I wish.  It's not really a matter of packetizer.com
> referring, but rather the RP querying packetizer.com to learn what it wants.
> My preference would be that the RP query using webfinger to see a link
> relation that has an href value equal to my OpenID identity (URI).

I prefer using my own domains - I use phill at hallambaker.com and
hallam at defaultdenysecurity.com for most purposes. They both redirect
to this same gmail account. The difference being that on this one I
have control.

I have no intention of setting up my own IdP for that purpose either.
If the scheme is going to work acceptably then it has to be possible
for people like me who have a domain but don't want to run an IDP of
their own can make use of other IDPs easily.

Whatever switching layer we need has to be able to support that use
case. It may be that even if we can in fact meet all the use case
requirements with SRV alone it is tactically advantageous to use
webfinger at least in the transitional phase.

The problem I see with any scheme that does not involve DNS switching
is that we then lack an ongoing proof of ownership of the name.

So for example, if alice is silly enough to use alice at comcast.com and
then Comcast tells her that they are selling her local cable co to
someone else and changing all the account names, alice has just lost
all the equity she has built up in that name. This is a problem in
this instance, as I found out myself as my cable co has changed its
name three times in the seven years I have used them.

But when I left VeriSign the company expressly wants all the rights I
may have acquired for pbaker at verisign.com out there in the net to
expire when they decide.

The solution to the comcast.com issue in my view has to be a solution
for all of Alice's internet activities. It has to work for email and
her blog and her jabber chat. Since they use DNS as the name scheme,
her only real solution to the comcast issue in that case is to buy her
own DNS name. That solution must be a sufficient solution for OpenID
as well - if it is going to deserve the term 'open'.

That is why one of the routes I see for evangelizing OpenID is to go
to the big DNS registrars with a value proposition: If they support
OpenID it will increase the value of the names they sell. I can go to
Bob Parsons with a really good argument that he can see a fast return
on investing in OpenID.

> I would expect the RP to maintain the OpenID URI as it would today.  It's
> that ID that should be bound to the account for identity purposes.

What happens under the covers is not really a concern to me at this
point. The original idea of the web was that the URIs could be messy
as they would never be seen by users. Believe it or not, one of the
innovations of Mosaic was to make it easy to see the URL and to enter
one to navigate to.

>> Alice quite likely has that setup because she wants to control who can
>> contact her and avoid spam. So I don't think that there is any real
>> problem with Alice remembering her accounts as alice at mail.com and
>> alice at idp.com in that instance.
>
> I think you could use either here.  As I said, both could be configured to
> provide the same information via webfinger.

You could use either, but you would be doing so for the express
purpose of achieving different effect.


> An enterprise is likely (though I can't say for sure) not going to advertise
> an IDP other than whatever *one* it selects, so your point is quite valid.
> The solution today, which I think is quite reasonable, is to associate
> multiple OpenID identities to an account.  With most web sites, I can store
> one of several identities, which would then allow me to add or drop
> identities as my professional relationships change.  (Then again, I also try
> to keep work and person stuff quite separate so as to avoid this issue from
> the start.)

One point to bear in mind that has recurred on numerous occasions is
that while we divide access control into authentication and
authorization, there is no such thing as an attribute free
authentication scheme, every authentication scheme we use in practice
blurs the line between the two.

So pbaker at verisign.com is not merely an opaque label for a username,
it has implicit authorization attributes and policy. An employee badge
is not merely an authentication token, it is an implicit bearer token
that usually allows the holder to be present on certain property.


Where the value add may come in for OpenID over what an IETF group
would have delivered is precisely considering this type of issue and
offering the type of useful but unenforceable guidance to deployers
that help them build a system that works well together rather than one
that works badly.



-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/


More information about the specs mailing list