I think we are actually getting to some useful stuff here. On Thu, Apr 15, 2010 at 2:56 PM, Paul E. Jones <[email protected]> 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 [email protected] and [email protected] 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 [email protected] 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 [email protected] 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 [email protected] and >> [email protected] 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 [email protected] 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/ _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
