[OpenID] Promoting delegation...

[Chris Messina]

Turns out people aren't apparently familiar with the delegation feature of OpenID, given the response to my comments on This Week in Google and Gina Tripani's followup post:

http://smarterware.org/6286/how-to-set-up-openid-on-your-own-domain/

Turns out people seem to like this feature after all!

Chris

--
Chris Messina
Open Web Advocate, Google

Personal: http://factoryjoe.com
Follow me on Buzz: http://buzz.google.com/chrismessina
...or Twitter: http://twitter.com/chrismessina

This email is:   [ ] shareable    [X] ask first   [ ] private

[James Walker]

I've often promoted delegation as one of the strongest things OpenID
has done for *user centric* identity. It'd be a real shame to lose
that power in vNext / Connect.

Glad to see you and Gina bringing (even) more awareness (than you already have)!

.j

> _______________________________________________
> general mailing list
> gen...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>

--
James Walker :: http://walkah.net/ :: http://james.status.net/
_______________________________________________
general mailing list
gen...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general

[Melvin Carvalho]

2010/6/18 Chris Messina <chris....@gmail.com>

Turns out people aren't apparently familiar with the delegation feature of OpenID, given the response to my comments on This Week in Google and Gina Tripani's followup post:

http://smarterware.org/6286/how-to-set-up-openid-on-your-own-domain/

Turns out people seem to like this feature after all!

This has always been one a really attractive feature of OpenID, imho

"I feel strongly about owning my identity online, mapping it to my nameplate domain"

I think some people like to have control over their own identity, and point it to a provider. 

Personally I link my homepage to both my OpenID and my WebID.  Both of which are authenticated from my browser client certificate.  I think this currently gives me the best of all worlds.
 

Chris

--
Chris Messina
Open Web Advocate, Google

Personal: http://factoryjoe.com
Follow me on Buzz: http://buzz.google.com/chrismessina
...or Twitter: http://twitter.com/chrismessina

This email is:   [ ] shareable    [X] ask first   [ ] private

[Nat Sakimura]

+1

We are talking about User Centric (and Citizen Centric in some
context) Identity.
Users should be able to choose whatever the authentication and
attribute service
they want to use. They should be able to change the service at any time.

There are many things that we need to deal with in this respect, but
that is what
this community is trying to get to, I think. At least, that is my core
philosophy
around OpenID, and that is what differentiate OpenID from other
Identity Frameworks.
(not saying it is the only one, btw.)

=nat

--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en

[Allen Tom]

As far as I know, delegation should continue to work in the Connect proposal. Delegation was pretty straightforward in OpenID 1.1, but became overly complex, if not broken, in OpenID 2.0.

Allen

[John Bradley]

The original Connect proposal uses a simple form of discovery (Not full webfinger/LRDD) for email type identifiers where only the domain portion is used.

That in principal forces delegation if supported to be domain based rather than user based.

As an example if I wanted to delegate my Yahoo email ID to another provider I couldn't do that.

While the protocol supports delegating out now in reality no major OP support individual XRDS to allow it.

The concern I have is that the Connect proposal needs to support some user centric discovery mechanism so that delegation in to a IdP from a personal domain can be made to work.

I understand that only discovering the host portion is more efficient.   

It will be a interesting conversation in the WG once we get going.

The important question is do we want personal discovery documents that can contain multiple relationships and perhaps authentication protocols  eg openID 2.0?

Regards

John B.

[Peter Watkins]

On Fri, Jun 18, 2010 at 11:51:16AM -0700, Chris Messina wrote:
> Turns out people aren't apparently familiar with the delegation feature of
> OpenID, given the response to my comments on This Week in Google and Gina
> Tripani's followup post:
>
> http://smarterware.org/6286/how-to-set-up-openid-on-your-own-domain/
>
> Turns out people seem to like this feature after all!

That's not at all what I'd consider "delegation". I opened your message
expecting to see some proposal for one identifier to delegate some kind
of authority to another identifier (e.g. a physician delegating to his
non-MD office manager authority to deal with billing systems).

(It would be nice if OpenID could solve that sort of delegation problem,
if the delegation tokens could be handled at the OP instead of multiple
disparate RP sites developing their own delegation models...)

I think this old feature of using discovery to associate URLs with
arbitrary 3rd-party OPs is probably going to become *less valuable* over
time, if only because OpenID is drifting toward 100% https operation, and
most small, personal domains will have a hard time coughing up the extra money
for the dedicated IPv4 address that's needed to run an https site (I assume
the IETF TLS working groups still hasn't made much headway in making
TLS v.Next support hostname negotiation, to say nothing of getting the
capability deployed to a significant majority of client devices). It would
subvert the whole https model if the very first step in discovery involves
requesting a document with an http: address like http://ginatrapani.org/ .

-Peter

[Nat Sakimura]

If it were just the issue of the IP Address, then would not the
signing the discovery document serve our purpose?

=nat

--

Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en

[John Panzer]

Yes.

--
--
John Panzer / Google
jpa...@google.com / abstractioneer.org / @jpanzer

[Peter Watkins]

On Sat, Jun 19, 2010 at 10:06:07AM +0900, Nat Sakimura wrote:
> If it were just the issue of the IP Address, then would not the
> signing the discovery document serve our purpose?

Signing with S/MIME key? Like I'd buy a cert for the CN myblog.com
and use it to sign the discovery info embedded in http://myblog.com/
if I can't run https://myblog.com/ ?

That might work, sure. I'd like to think more about that, but at
first glance that looks like a pretty elegant solution. It would
be nice if the signed assertion for the discovery info could include
an expiration time, since I don't think there's any way to repudiate
an individual S/MIME signature (I don't know much about S/MIME). You
would want the owner of myblog.com to be able to publish a new discovery
document pointing to a new OP without worry of some MITM+replay attack
using the old signed discovery info. With normal OpenID https discovery
you don't need to worry about that, as the RP will only trust info
retrieved in real time. Adding an expiry time to an S/MIME signed
discovery document would give the domain owner the *option* of deciding
to periodically re-sign his/her discovery info if desired.

(Alternately, I suppose you could just argue that the domain owner
could revoke the myblog.com cert and sign the new discovery info with
a new/replacement cert. As long as the CA supported OCSP and the RP
performed OCSP validation, that would work, too.)

-Peter

> On Sat, Jun 19, 2010 at 10:01 AM, Peter Watkins <pet...@tux.org> wrote:
> > On Fri, Jun 18, 2010 at 11:51:16AM -0700, Chris Messina wrote:
> >> Turns out people aren't apparently familiar with the delegation feature of
> >> OpenID, given the response to my comments on This Week in Google and Gina
> >> Tripani's followup post:
> >>
> >> http://smarterware.org/6286/how-to-set-up-openid-on-your-own-domain/

> > I think this old feature of using discovery to associate URLs with

> > arbitrary 3rd-party OPs is probably going to become *less valuable* over
> > time, if only because OpenID is drifting toward 100% https operation, and
> > most small, personal domains will have a hard time coughing up the extra money
> > for the dedicated IPv4 address that's needed to run an https site (I assume
> > the IETF TLS working groups still hasn't made much headway in making
> > TLS v.Next support hostname negotiation, to say nothing of getting the
> > capability deployed to a significant majority of client devices). It would
> > subvert the whole https model if the very first step in discovery involves
> > requesting a document with an http: address like http://ginatrapani.org/ .