[OpenID] HTML-Based Discovery incompatibilities

[Peter Williams]

Good luck in the IETF security area directorate.

In an analogous study area to openid, only one serious effort was made in IETF: SPKI (Rivest, Lampson, et al contributing SDSI). Everything other WG output is strongly TTP-centric, where there always ultimately exists a formal control authority governing a user's ability to communicate.

Getting on for being 10 years old, ideas in the SPKI RFCs may be worth re-visiting -  if only to contemplate what a harmonized OAUTH + OpenID world might look like. SPKI nicely characterized how authorities and users might co-exist, for different trust overlays.

Given the nature of an IETF BOF process advocating the formation of a WG, it seems more than appropriate to canvass folk here on common areas related to OAUTH ...for the OAUTH BOF. To stuff an IETF WG, one has to first collect enough birds.


From: Eran Hammer-Lahav [mailto:eran at hueniverse.com]
Sent: Friday, January 09, 2009 8:17 AM
To: Peter Williams; Martin Atkins
Cc: general at openid.net
Subject: RE: [OpenID] HTML-Based Discovery incompatibilities

I haven't thought enough about this topic to have an educated opinion. But nothing I wrote on this matter suggests removing of any feature of functionality, especially the user's ability to control delegation.

With regard to the integration with OAuth, OAuth currently does not allow the user to control delegation. Only the Service Provider has the power to mint Access Tokens and control them. While the spec requires that the end-user is part of the process, the user on it own cannot do much. During the IETF BoF the idea was raised that OAuth should at a minimum allow users to mint their own tokens and hand them directly to Consumers without the need for the SP to be involved. This of course would require some form of signature allowing the SP to verify such self-minted tokens.

This proposal has yet to be seriously discussed.

EHL



From: Peter Williams [mailto:pwilliams at rapattoni.com]
Sent: Friday, January 09, 2009 7:04 AM
To: Eran Hammer-Lahav; Martin Atkins
Cc: general at openid.net
Subject: RE: [OpenID] HTML-Based Discovery incompatibilities

If you had a magic wand to wave in the OAUTH + OpenID integration (which I hope happens),


1.       would you eliminate the concept of end-user controlled delegation?

Today, the ONLY way a user can express the requirement to have myopenid invoke https between the user's browser and myopenid for user authentication is through the user-controlled metadata used also for delegation.


2.       Would you eliminate the concept of a user being able to require an OP to authentication the user over https?

I ask these particular questions as many folk in more traditional TTP IDP community cultures feel end-users really ought to have NO say and NO control over those issues. They would typically argue that only "authorities" have a "proper" role in those areas, whether the authority is the RP, the OP or the vanity openid provider (i-broker/ISP).

They would argue that the end-user is NEVER an authority. Rather, the user has only one role: to be a subscriber to one of other authorities policies. Only if the authority can continually trust and verify the end-user against the policy would such an authority authorize the user to participate in the community. Without an explicit authorization, access to the interworking community will be denied by default.

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Eran Hammer-Lahav
Sent: Thursday, January 08, 2009 1:32 PM
To: Martin Atkins
Cc: general at openid.net
Subject: Re: [OpenID] HTML-Based Discovery incompatibilities

problem with OpenID, unlike most other protocols in this space is that it is too close to the end-user surface.

So if this feature is not widely adopted, it leads directly to breaking the faith the end-user has in the entire protocol.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090109/4682f88d/attachment-0002.htm>