[OpenID] HTML-Based Discovery incompatibilities

Fri Jan 9 18:39:40 UTC 2009

you can draw interesting parallels with openid auth protocol with http://www.ietf.org/rfc/rfc2693.txt

SPKI section 5 -> openid's assertion sig validation by OP, over private associations

SPKI section 4 -> handling differences in delegation expectations between OAUTH and OpenID (and authZ focus vs authN focus)

SPKI section 2.8 -> letting the sequence of redirects ("xri resolution across namespaces") used during openid discovery influence an RP's acceptance of roots

SPKI section 5.2 -> addresses INDEPENDNET OCSP servers, that guard against impact of cipher compromises in https based on PKI ciphersuites

SPKI section 6.5.7 -> allow certain openid OPs to act as a extremely-controlling trust overlay based on "extended"  https semantics, without imposing the control model on the infrastructure by default

SPKI section 7.5 -> aligns nicely with the multiple nyms model  of UCI and openid discovery (when based on http, not XRIs)

If you can avoid getting too upset about the (academic) rant-components built into the material (one of the authors went  on to create xml dsig  - as an  'antidote' to the complexity of the 0.5 page X.509 need to express it's canonicalization model :) ) and are not fazed by the pseudo-math, it's worth a read. I'm pretty dumb (all I do is buy stuff from technologists, these days) and it didn't faze me.

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Peter Williams
Sent: Friday, January 09, 2009 8:37 AM
To: Eran Hammer-Lahav; Martin Atkins
Cc: general at openid.net
Subject: Re: [OpenID] HTML-Based Discovery incompatibilities

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/0beae7c9/attachment-0002.htm>