RE: Re[4]: [PROPOSAL] authentication age

[Drummond Reed]

+1 to one key takeaway from this whole thread: that the
marketing/evangelism/messaging around OpenID MUST be very careful to clearly
communicate, in Gabe's words, "what it can and cannot do right now".
Especially when it comes to hard problems like authentication context and
circles of trust that SAML and Liberty Alliance have been cranking for 5+
years at. As long as we " communicated clearly so expectations aren't raised
and then not met" then we should give OpenID the runway it needs to grow
into those problems, just like 802.11 started "thin" and grew to become
nearly ubiquitous.

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Gabe Wachob
Sent: Wednesday, October 04, 2006 9:09 PM
To: 'Chris Drake'
Cc: specs@openid.net
Subject: RE: Re[4]: [PROPOSAL] authentication age

Chris-
I don't mean to be pessimistic about OpenID *AT ALL* - I truly do
believe that OpenID *WILL* get to the point where its valuable for the Visas
of the world. I don't want to stall it for the other use cases that are
motivating the people who are currently involved - I think OpenID can
quickly evolve when needed. OpenID should be as lightweight as needed for
the use case - and I so I think OpenID is great where it is. 
Its just that we have to be clear what its trying to do today and
what it is NOT trying to do. I think we'll surprise some people (like you) -
but in the long run, the credibility will be there - I *KNOW* the folks who
are involved with OpenID are smart and know what it can and cannot do right
now. We just have to make sure that its being communicated clearly so
expectations aren't raised and then not met...

-Gabe

> -Original Message-
> From: Chris Drake [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 04, 2006 9:00 PM
> To: Gabe Wachob
> Cc: 'Kevin Turner'; specs@openid.net
> Subject: Re[4]: [PROPOSAL] authentication age
> 
> Hi Gabe,
> 
> Beautifully worded, and (IMHO) an extremely valuable real-world
> opinion.  I too believe OpenID is currently a "non-starter".  I have
> dual vested interests:  I want OpenID to succeed, *especially* for RPs
> like Visa, since my IdP makes money from supporting OpenID only when
> OpenID ends up getting used.  I also believe that an IdP (and mine in
> particular) is well suited for deploying secure technology (eg: two
> factor tokens).  If, aside from making OpenID actually *work* for the
> likes of Visa, we can build in the ability to provide a tangible
> *benefit* to Visa from using it (that is: allow visa to REQUIRE that a
> user has authenticate via two-factor means, to an accredited - i.e:
> explicitly trusted by Visa - IdP) then we've not only cemented the
> future of OpenID, we've gone an improved a pile of security problems
> along the way.
> 
> Kind Regards,
> Chris Drake
> 1id.com
> 
> Thursday, October 5, 2006, 1:41:34 PM, you wrote:
> 
> GW> Chris-
> GW>   As someone who has recently come from working in the financial
> GW> sector (Visa), its clear that OpenID is NOT intended for
> authentication
> GW> where the *relying party* cares about how the authentication is
> performed.
> 
> GW>   At places like Visa and for home banking, this means that OpenID,
> GW> without something more, is clearly a . These relying parties want
> GW> to know exactly how their users are being authenticated because their
> GW> business is all about risk management and creating business
> opportunities
> GW> around very good knowledge of the risk profile of each transaction
> type.
> 
> GW>   That all being said, I believe it should be possible to layer on
> GW> OpenID a form of IDP control such that a relying party can require a
> certain
> GW> class or group of IDPs be used when presenting authentication
> assertions to
> GW> them. The actual *policy* for how these IDPs are approved is probably
> GW> orthogonal to the protocol spec, but "secure" identification of those
> IDPs
> GW> (relative to some trust root, etc) could probably be made into an
> extension
> GW> usable for those parties who want it.
> 
> GW>   My guess is that culturally, most people involved in OpenID have
> GW> *not* been interested in addressing these concerns. However,
> expectations
> GW> need to be better managed around these sort of "relying-party cares"
> GW> scenarios, because its not obvious without actually reading the specs
> GW> themselves...
> 
> GW>   -Gabe
> 
> >> -Original Message-
> >> From: [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED] On Behalf
> >> Of Chris Drake
> >> Sent: Wednesday, October 04, 2006 8:26 PM
> >> To: Kevin Turner
> >> Cc: specs@openid.net
> >> Subject: Re[2]: [PROPOSAL] authentication age
> >>
> >> Hi Kevin,
> >>
> >> Sounds like you're leaning towards a root authority for IdPs who can
> >> audit procedures and verify protection in order to sign the IdP's
> >> keys?
> >>
> >> Joe blogger doesn't care much about identity assertions from an IdP,
> >> but it's a reasonable bet to expect 

RE: Re[4]: [PROPOSAL] authentication age

[Gabe Wachob]

Chris-
I don't mean to be pessimistic about OpenID *AT ALL* - I truly do
believe that OpenID *WILL* get to the point where its valuable for the Visas
of the world. I don't want to stall it for the other use cases that are
motivating the people who are currently involved - I think OpenID can
quickly evolve when needed. OpenID should be as lightweight as needed for
the use case - and I so I think OpenID is great where it is. 
Its just that we have to be clear what its trying to do today and
what it is NOT trying to do. I think we'll surprise some people (like you) -
but in the long run, the credibility will be there - I *KNOW* the folks who
are involved with OpenID are smart and know what it can and cannot do right
now. We just have to make sure that its being communicated clearly so
expectations aren't raised and then not met...

-Gabe

> -Original Message-
> From: Chris Drake [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 04, 2006 9:00 PM
> To: Gabe Wachob
> Cc: 'Kevin Turner'; specs@openid.net
> Subject: Re[4]: [PROPOSAL] authentication age
> 
> Hi Gabe,
> 
> Beautifully worded, and (IMHO) an extremely valuable real-world
> opinion.  I too believe OpenID is currently a "non-starter".  I have
> dual vested interests:  I want OpenID to succeed, *especially* for RPs
> like Visa, since my IdP makes money from supporting OpenID only when
> OpenID ends up getting used.  I also believe that an IdP (and mine in
> particular) is well suited for deploying secure technology (eg: two
> factor tokens).  If, aside from making OpenID actually *work* for the
> likes of Visa, we can build in the ability to provide a tangible
> *benefit* to Visa from using it (that is: allow visa to REQUIRE that a
> user has authenticate via two-factor means, to an accredited - i.e:
> explicitly trusted by Visa - IdP) then we've not only cemented the
> future of OpenID, we've gone an improved a pile of security problems
> along the way.
> 
> Kind Regards,
> Chris Drake
> 1id.com
> 
> Thursday, October 5, 2006, 1:41:34 PM, you wrote:
> 
> GW> Chris-
> GW>   As someone who has recently come from working in the financial
> GW> sector (Visa), its clear that OpenID is NOT intended for
> authentication
> GW> where the *relying party* cares about how the authentication is
> performed.
> 
> GW>   At places like Visa and for home banking, this means that OpenID,
> GW> without something more, is clearly a . These relying parties want
> GW> to know exactly how their users are being authenticated because their
> GW> business is all about risk management and creating business
> opportunities
> GW> around very good knowledge of the risk profile of each transaction
> type.
> 
> GW>   That all being said, I believe it should be possible to layer on
> GW> OpenID a form of IDP control such that a relying party can require a
> certain
> GW> class or group of IDPs be used when presenting authentication
> assertions to
> GW> them. The actual *policy* for how these IDPs are approved is probably
> GW> orthogonal to the protocol spec, but "secure" identification of those
> IDPs
> GW> (relative to some trust root, etc) could probably be made into an
> extension
> GW> usable for those parties who want it.
> 
> GW>   My guess is that culturally, most people involved in OpenID have
> GW> *not* been interested in addressing these concerns. However,
> expectations
> GW> need to be better managed around these sort of "relying-party cares"
> GW> scenarios, because its not obvious without actually reading the specs
> GW> themselves...
> 
> GW>   -Gabe
> 
> >> -Original Message-
> >> From: [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED] On Behalf
> >> Of Chris Drake
> >> Sent: Wednesday, October 04, 2006 8:26 PM
> >> To: Kevin Turner
> >> Cc: specs@openid.net
> >> Subject: Re[2]: [PROPOSAL] authentication age
> >>
> >> Hi Kevin,
> >>
> >> Sounds like you're leaning towards a root authority for IdPs who can
> >> audit procedures and verify protection in order to sign the IdP's
> >> keys?
> >>
> >> Joe blogger doesn't care much about identity assertions from an IdP,
> >> but it's a reasonable bet to expect that a Bank might care...
> >>
> >> Kind Regards,
> >> Chris Drake
> >>
> >>
> >> ___
> >> specs mailing list
> >> specs@openid.net
> >> http://openid.net/mailman/listinfo/specs
> 


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re[4]: [PROPOSAL] authentication age

[Chris Drake]

Hi Gabe,

Beautifully worded, and (IMHO) an extremely valuable real-world
opinion.  I too believe OpenID is currently a "non-starter".  I have
dual vested interests:  I want OpenID to succeed, *especially* for RPs
like Visa, since my IdP makes money from supporting OpenID only when
OpenID ends up getting used.  I also believe that an IdP (and mine in
particular) is well suited for deploying secure technology (eg: two
factor tokens).  If, aside from making OpenID actually *work* for the
likes of Visa, we can build in the ability to provide a tangible
*benefit* to Visa from using it (that is: allow visa to REQUIRE that a
user has authenticate via two-factor means, to an accredited - i.e:
explicitly trusted by Visa - IdP) then we've not only cemented the
future of OpenID, we've gone an improved a pile of security problems
along the way.

Kind Regards,
Chris Drake
1id.com

Thursday, October 5, 2006, 1:41:34 PM, you wrote:

GW> Chris-
GW> As someone who has recently come from working in the financial
GW> sector (Visa), its clear that OpenID is NOT intended for authentication
GW> where the *relying party* cares about how the authentication is performed.

GW> At places like Visa and for home banking, this means that OpenID,
GW> without something more, is clearly a . These relying parties want
GW> to know exactly how their users are being authenticated because their
GW> business is all about risk management and creating business opportunities
GW> around very good knowledge of the risk profile of each transaction type.

GW> That all being said, I believe it should be possible to layer on
GW> OpenID a form of IDP control such that a relying party can require a certain
GW> class or group of IDPs be used when presenting authentication assertions to
GW> them. The actual *policy* for how these IDPs are approved is probably
GW> orthogonal to the protocol spec, but "secure" identification of those IDPs
GW> (relative to some trust root, etc) could probably be made into an extension
GW> usable for those parties who want it. 

GW> My guess is that culturally, most people involved in OpenID have
GW> *not* been interested in addressing these concerns. However, expectations
GW> need to be better managed around these sort of "relying-party cares"
GW> scenarios, because its not obvious without actually reading the specs
GW> themselves...

GW> -Gabe

>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf
>> Of Chris Drake
>> Sent: Wednesday, October 04, 2006 8:26 PM
>> To: Kevin Turner
>> Cc: specs@openid.net
>> Subject: Re[2]: [PROPOSAL] authentication age
>> 
>> Hi Kevin,
>> 
>> Sounds like you're leaning towards a root authority for IdPs who can
>> audit procedures and verify protection in order to sign the IdP's
>> keys?
>> 
>> Joe blogger doesn't care much about identity assertions from an IdP,
>> but it's a reasonable bet to expect that a Bank might care...
>> 
>> Kind Regards,
>> Chris Drake
>> 
>> 
>> ___
>> specs mailing list
>> specs@openid.net
>> http://openid.net/mailman/listinfo/specs



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: Re[2]: [PROPOSAL] authentication age

[Gabe Wachob]

Chris-
As someone who has recently come from working in the financial
sector (Visa), its clear that OpenID is NOT intended for authentication
where the *relying party* cares about how the authentication is performed. 

At places like Visa and for home banking, this means that OpenID,
without something more, is clearly a non-starter. These relying parties want
to know exactly how their users are being authenticated because their
business is all about risk management and creating business opportunities
around very good knowledge of the risk profile of each transaction type. 

That all being said, I believe it should be possible to layer on
OpenID a form of IDP control such that a relying party can require a certain
class or group of IDPs be used when presenting authentication assertions to
them. The actual *policy* for how these IDPs are approved is probably
orthogonal to the protocol spec, but "secure" identification of those IDPs
(relative to some trust root, etc) could probably be made into an extension
usable for those parties who want it. 

My guess is that culturally, most people involved in OpenID have
*not* been interested in addressing these concerns. However, expectations
need to be better managed around these sort of "relying-party cares"
scenarios, because its not obvious without actually reading the specs
themselves...

-Gabe

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Chris Drake
> Sent: Wednesday, October 04, 2006 8:26 PM
> To: Kevin Turner
> Cc: specs@openid.net
> Subject: Re[2]: [PROPOSAL] authentication age
> 
> Hi Kevin,
> 
> Sounds like you're leaning towards a root authority for IdPs who can
> audit procedures and verify protection in order to sign the IdP's
> keys?
> 
> Joe blogger doesn't care much about identity assertions from an IdP,
> but it's a reasonable bet to expect that a Bank might care...
> 
> Kind Regards,
> Chris Drake
> 
> 
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re[2]: [PROPOSAL] authentication age

[Chris Drake]

Hi Kevin,

Sounds like you're leaning towards a root authority for IdPs who can
audit procedures and verify protection in order to sign the IdP's
keys?

Joe blogger doesn't care much about identity assertions from an IdP,
but it's a reasonable bet to expect that a Bank might care...

Kind Regards,
Chris Drake


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] authentication age

[Kevin Turner]

Pretty much the *only* relationship that exists between the RP and the
IdP is that the authentication method is trustworthy because the user
has decided it is.  I believe this proposal places additional demands on
that, and that those are demands that the protocol cannot fully support.

When you ask an OpenID IdP for information, you are not asking some
ultimately trusted third party, you're asking whomever End User chose to
appoint as her agent.  Which is quite possibly an entity entirely
controlled by End User herself.  All information sent by the IdP is
*only as true as the user wants it to be.*

So I think the question is, who will catch the blame when the RP's
requirements for credentials checking aren't followed?  Will you be able
to say "End User chose to ignore our requirements, so it's End User's
problem."?  If so, this proposal is okay.  But if your Draconian
Security Officer will say "When I said to require up-to-the-moment
credential checks to access our resources, I did mean REQUIRE, not just
'require *if the user feels like it.*'  Your implementation failed to
enforce our requirements.  You're fired," then that is not so good for
you.

My worry is that features like this will mislead the RP developers into
thinking they have more control over the authentication protocol than
they really do, into thinking that they can exert the level of control
required by that Draconian Security Officer, when OpenID actually leaves
all those controls in the hands of the user and their chosen IdP.

Session age isn't the only thing application developers will be
accustomed to having control over.  Password strength and password
lifetime are a few other obvious examples.  (Although I think it's rare
to see password lifetime restrictions on the Web these days, it was
popular to do in other applications for a while.)  But with OpenID, the
RP won't have real control over of any of those things.  I'm concerned
that adding parameters that suggest it does will do more harm than good.

The RP doesn't even have the capacity to audit any of those processes,
to find out what procedure was followed.  Now that I think about it,
that may be the real problem: How useful is it to specify security
requirements that you can't audit?


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Proposal: IdP-supported delegation

[Chris Drake]

Hi All,

I've been absent 2 months, and missed the announcement of this list.

On a brief skim of the archive re delegation, I can't see a clearcut
agreement yet?  There was also talk of omitting delegation from the
first draft - did this omission go ahead? 

I would like to propose the following.

1. RP (Relying Party) *requests* a users identifier (eg: global iname)
   in RPs login  on their web site, however, the post target for
   this form is *not* the RP, but instead the RP's IdP (iBroker).

2. Users may...
   A) Key in their unique global identifier
   B) Key in their actual IdP URL
   C) Enter nothing at all and click either the "login" button, or the
  inames logo
   D) Not click anything at all (as would be the case if their browser
  held an RP-issued cookie stating "stay logged on")

3. The RPs iBroker agrees to suitably issue HTTP redirects to the
   correct iBroker should they discover they're not the correct IdP
   for the user.
   

Solves:

   i) eradicates the difficult-for-end-users-to-understand problem of
  trying to explain to them why they formerly needed to enter
  other stuff besides their iname to log in - from a users
  perspective, they only need log in one time, using their genuine
  favorite identifier.
  
  ii) Privacy problems solved: control over which identifier to
  subsequently present to RP is returned to the user.  At NO time
  does the users keyed identifier need or get communicated to the
  RP

Facilitates:
  
 iii) Genuine single-signon (SSO) - Just because a user only has to
  type their *password* once, doesn't make that a "single sign on"
  in my opinion.  If I have SIGNED ON - I do not expect to have to
  re-type my wretched identifier every time I visit a new RP.  I
  just want to click *once*, or, not even click at all.

  iv) A single sign off (SSOFF?) - the "log out" problem: many RPs
  support "stay logged on" features, so to expect an RP to use
  OpenID, we should also support this, or risk them all having to
  implement this themselves, which robs our users of the ability
  to "log out" from every place they are currently logged in to.

   v) Anonymous single signon, but still using just our users favorite
  identifier

  vi) Automatic IdP-provided unique identifier provision - RP site
  always gets the same identifier for the user, which is never the
  same as the identifier the user keyed in, and such identifier is
  never shared amongst RPs

 vii) Double-blind anonymous single sign on (neither does the RP know
  the users identifier nor iBroker, nor does the iBroker know what
  RP the user is signing in to.) [requires a nonce, which we
  already have for other reasons anyway]

viii) Lets a user log in to any site they've joined, simply by
  clicking on it in the list on their own personal iBroker sites
  page at their IdP.
  
Requires:

  ix) iBrokers to co-operate, and possibly someone to administer a
  root key to sign certificates to allow RPs to automatically
  ascertain the accreditation and policy status of the iBroker

In general, my coding and standards philosophy is to cater for as much
as possible, even if it's not all initially implemented.  Also in
general, my UI philosophy is to make everything as utterly simple for
users as we possibly can.  I think my the above proposal caters for
both.

As an IdP myself (1id.com) I offer to implement the above. I also
offer my response to Josh Hoyts worry:-

>On Sep 4, 2006, at 13:00, Josh Hoyt wrote:
>> I think that disclosing the identifier to the *IdP* is a non-issue.
>> The only potential issue is that some IdP may choose not to support
>> delegation in order to lock in users.

My IdP will properly honor delegation issues, and will not store or
use the flow of other IdP's identifiers for anything.  (indeed, if
delegation is global, then all RPs for whom I am their iBroker will
therefore gain the advantage that even if other IdPs don't commit to
the same practice as me - all their users still get the advantages of
a working and functional solution, by virtue of my place in the
middle - e.g. my step numbered "3." above)

Kind Regards,
Chris Drake


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: openid.delegate explained.

[Dick Hardt]

On 4-Oct-06, at 1:27 PM, Martin Atkins wrote:

> Dick Hardt wrote:
>>
>> The RP needs to resolve the identifier to check who is authorative
>> for it.
>>
>> If you create a mechanism for how to resolve who owns
>> "mailto:[EMAIL PROTECTED]", then it works.
>>
>> That functionality is needed to prevent any IdP from being
>> authoritative for an arbitrary URI.
>>
>> -- Dick
>
> The public URI is still resolvable by the RP as is necessary.
>
> But the RP never uses the openid.delegate value; it simply passes  
> it on
> to the IdP where the IdP can then do what it likes with it. In
> LiveJournal's case, it's simply a regex to see if it matches
> http://([a-z0-9\-]+).livejournal.com/, which could easily be
> mailto:([a-z0-9\-]+)@livejournal.com, or anything else.

My mistake. I forgot that there is the openid.server parameter in the  
HTML at the public URI -- had thought that the server was discovered  
from the openid.delegate

So it does look like the openid.delegate can be any string the IdP  
wants the user to put in there to uniquely identify the user, and  
does not need to be resolvable

-- Dick



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

[OT] our cookie expiration

[Kevin Turner]

On Wed, 2006-10-04 at 19:40 +0100, Martin Atkins wrote:
> it's been my experience that users are willing to trade an awful lot of 
> security to avoid software nagging at them repeatedly.

Which goes back to what Dick was saying about his myopenid.com login
cookie not expiring.  Users didn't like logging in after every time
their browser restarted, so we made the cookie persistent.

Does that make us a "BadCitizen-IdP"?  I don't believe it does.
Expiring cookies sooner seems beneficial for a particular group of
users, those who are:

1) cautious enough to not leave their myopenid.com password in their
browser's password cache, and
2) careless enough to leave their desktops unlocked when unattended.

The combination of those two contrasting qualities seems likely to be a
small subset of our user base.  We hoped the remaining users who really
wanted to not have old login cookies laying around would avail
themselves of the "sign off" button.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: openid.delegate explained.

[Martin Atkins]

Dick Hardt wrote:
> 
> The RP needs to resolve the identifier to check who is authorative  
> for it.
> 
> If you create a mechanism for how to resolve who owns  
> "mailto:[EMAIL PROTECTED]", then it works.
> 
> That functionality is needed to prevent any IdP from being  
> authoritative for an arbitrary URI.
> 
> -- Dick

The public URI is still resolvable by the RP as is necessary.

But the RP never uses the openid.delegate value; it simply passes it on 
to the IdP where the IdP can then do what it likes with it. In 
LiveJournal's case, it's simply a regex to see if it matches 
http://([a-z0-9\-]+).livejournal.com/, which could easily be 
mailto:([a-z0-9\-]+)@livejournal.com, or anything else.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] authentication age

[Martin Atkins]

Dick Hardt wrote:
> I find the argument that IdPs will just return success all the time  
> to be baseless. A good IdP will do what it thinks is best for its  
> users. A bad IdP will not have any users for any period of time.  

I suppose it depends on what you consider to be "bad". Consider this:

* We have an RP that asks for a session age limit of one hour.

* GoodCitizen-IdP respects the session age thing and asks user to log in 
again if it's been over an hour since they last did so.

* BadCitizen-IdP just ignores the flag and has sessions that last until 
the user closes his browser, but it lies to the RP and says that it 
respected the flag.

The user experience on GoodCitizen-IdP is "damnit, why do I have to keep 
logging in over and over again?!". The user is likely to be much happier 
with BadCitizen-IdP because he only has to log in once each day.

While it's true that BadCitizen-IdP might put its users at more risk, 
it's been my experience that users are willing to trade an awful lot of 
security to avoid software nagging at them repeatedly.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Questions about OpenID Attribute Properties Draft 1

[Dick Hardt]

On 4-Oct-06, at 11:20 AM, Frank I. Reiter wrote:

> Dick Hardt wrote:
>> Thanks!
>>
>> btw: I don't think you are signed up for the specs list, so as an  
>> admin I keep getting a moderate email.
> Perhaps as an admin you can either sign me up, or tell me to stop  
> CCing there.  I couldn't see how to join and it seemed rude not to  
> copy a list that was copied my my message's antecedent. :)

email [EMAIL PROTECTED] :-)

>
> Are you going to IIW in December?

yes
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

[PROPOSAL] Separate Public Identifier from IdP Identifier

[Martin Atkins]

Currently the conceptual model is that each user has a "public" (that 
is, presented to RPs) identifier, but can optionally create additional 
identifiers which "delegate" to the real identifier. The delegate 
functionality has several purposes, including:
  * "Vanity" identifiers on personal domains while letting someone else 
do the hard work in running the IdP.
  * Ability to switch IdPs without losing identity

However, experience has shown that the above model is often difficult to 
grasp for those new to OpenID. This proposal is really just a set of 
terminology changes and an alternative conceptual model that aim to make 
the delegate functionality easier to understand. It does not change the 
mechanism of delegation at all, though it does change the discovery 
protocol.

I've placed the full proposal on the OpenID wiki:
 


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: openid.delegate explained.

[Dick Hardt]

On 4-Oct-06, at 10:52 AM, Martin Atkins wrote:

>
>>> And all you've achieved here is to hand your identifier over to  
>>> Brad.
>>
>> Not at all! My IdP will only accept my credentials. If Brad pointed
>> his identifier to my IdP, he'd have handed it over to me, but  
>> there is
>> no way that he can use MY IdP even though it would make an assertion
>> about /his/ URL.
>>
>
> Okay. I misunderstood your scenario.
>
> Now that I understand what you mean, this makes me think all the more
> that the current "delegate" identifier should just be "token I log  
> into
> my IdP with" and have no other meaning. I'm not really bothered about
> whether it remains a URI or just becomes some opaque string.
>
> The nice thing about separating these two issues is that, even if we
> retain the requirement that this be a URI, it doesn't need to be a
> resolvable URI. I could give "mailto:[EMAIL PROTECTED]" to a  
> hypothetical
> IdP that identifies users by email addresses, for example.

The RP needs to resolve the identifier to check who is authorative  
for it.

If you create a mechanism for how to resolve who owns  
"mailto:[EMAIL PROTECTED]", then it works.

That functionality is needed to prevent any IdP from being  
authoritative for an arbitrary URI.

-- Dick
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Questions about OpenID Attribute Properties Draft 1

[Dick Hardt]

On 4-Oct-06, at 10:07 AM, Frank I. Reiter wrote:

> Dick Hardt wrote:
>> First of all, the list of properties is not part of the spec. Anyone
>> can define a new URI to be a new property, the properties do not need
>> be under openid.net at all.
>>
>> I would hope that sites would start to define their own properties at
>> some point in the future.
> So then why do we have:
>
> http://openid.net/schema/contact/web/Amazon
>
> as part of the "list of standard attribute property names for use with
> the attribute exchange service", if Amazon can define:
>
> http://amazon.com/schema/users/userid
>
> whenever they like? (Same question for all other service providers
> specifically identified in the spec).

Because it is hard to convince Amazon that is something useful to do  
right now!

But as sites see OpenID being adopted, then they hopefully will do it.

Frank: if you are interested in schema, it would be great for you to  
participate in the Identity Schema activity that Paul Trevithick is  
organizing.

http://wiki.idcommons.net/moin.cgi/IdentitySchemasCharter

Clearly I need to spend some time describing the vision that we have  
for properties as we have talked to many people and have some  
advanced thinking, but have not put it into a readily digestible form.

-- Dick

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: openid.delegate explained.

[Martin Atkins]

>> And all you've achieved here is to hand your identifier over to Brad.
> 
> Not at all! My IdP will only accept my credentials. If Brad pointed
> his identifier to my IdP, he'd have handed it over to me, but there is
> no way that he can use MY IdP even though it would make an assertion
> about /his/ URL.
> 

Okay. I misunderstood your scenario.

Now that I understand what you mean, this makes me think all the more 
that the current "delegate" identifier should just be "token I log into 
my IdP with" and have no other meaning. I'm not really bothered about 
whether it remains a URI or just becomes some opaque string.

The nice thing about separating these two issues is that, even if we 
retain the requirement that this be a URI, it doesn't need to be a 
resolvable URI. I could give "mailto:[EMAIL PROTECTED]" to a hypothetical 
IdP that identifies users by email addresses, for example.

Now that I've collected my thoughts a bit more I'll post this as a 
top-level proposal and stop clogging up this thread with my rambling. :)

Cheers,
Martin

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Questions about OpenID Attribute Properties Draft 1

[Dick Hardt]

On 4-Oct-06, at 4:53 AM, Frank I. Reiter wrote:

> Dick Hardt wrote:
>> Need the name of the site in the property otherwise the RP won't be
>> able to ask for it.
>>
>> previous suggestion was that the name should be a domain name "../
>> flickr.com" vs "../flickr"
>>
>> I would like to make it really easy for sites to get added to the
>> property list.
>>
>
> Agree.  What if it was contact/namedservice/{URI}, with any valid URI.
> this allows any service provider to add itself without changing the  
> spec.

First of all, the list of properties is not part of the spec. Anyone  
can define a new URI to be a new property, the properties do not need  
be under openid.net at all.

I would hope that sites would start to define their own properties at  
some point in the future.

-- Dick


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Wrapping Up Proposals

[Dick Hardt]

On 3-Oct-06, at 11:48 PM, Josh Hoyt wrote:

> On 10/3/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
>> > * Authentication age
>> > (http://openid.net/pipermail/specs/2006-September/000141.html)
>> >   Still being discussed, varying opinions on if the spec  
>> mandates
>> > this will IdPs cooperate.  Proposal of having it as an extension.
>>
>> +1 - per other email, let's get the feature in there. The IdP is
>> already managing session age. Having it as an extension is going to
>> add complexity to RP code as they have to discover if they can have
>> that as a parameter. This seems like huge overhead to determine a
>> single parameter
>
> There are other related session-management issues that need to be
> addressed, so I think it's silly to say that it'd be an extension for
> one parameter. I'd like it to be in a different spec so that those
> issues can be hashed out without having to update the core
> specification. Other things that might go in that spec include
> single-sign-off and the IdP advising the RP that the assertion is only
> good for a certain period of time.

session age is part of many existing sites coding patterns, it is a  
request we received a number of times when designing SXIP 1.0
NOT having session age now will limit who will adopt OpenID 2.0

Of all the points in discussion, I feel the most strongly about this  
one being in the spec as for many RPs this is an important aspect of  
AuthN.

single-sign-off and assertion expiry are not part of existing coding  
patterns.

I don't want to start a discussion on single-sign-off and assertion  
expiry, but here is my experience:

single-sign-off is impractical and although it seems to add value,  
our experience with SXIP 1.0 was that it did not, that implementing  
was difficult, and that users did not see value

authn assertion expiry does not seem to have value -- SAML does not  
use it, I would see the RP having its own session age to determine if  
the session is still valid. Perhaps there is a use case I am missing.


having spent considerable time on single-sign-off, it is not practical

having an authN assertion valid for a certain period of time is  
pretty meaningless as well

the RP knowing how long the user authn is useful and is part of  
existing coding patterns in websites



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: Questions about OpenID Attribute Properties Draft 1

[Drummond Reed]

>> Dick Hardt wrote:
>>
>> Need the name of the site in the property otherwise the RP won't be  
>> able to ask for it.
>>
>> previous suggestion was that the name should be a domain name "../ 
>> flickr.com" vs "../flickr"
>>
>> I would like to make it really easy for sites to get added to the  
>> property list.
>>  
>Frank I. Reiter wrote:
>
>Agree.  What if it was contact/namedservice/{URI}, with any valid URI.  
>this allows any service provider to add itself without changing the spec.

Bingo! That's the pattern we use in XDI, Frank -- every namespace can extend
the dictionary under their own namespace.

=Drummond 

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: openid.delegate explained.

[Josh Hoyt]

On 10/3/06, Martin Atkins <[EMAIL PROTECTED]> wrote:
> And all you've achieved here is to hand your identifier over to Brad.

Not at all! My IdP will only accept my credentials. If Brad pointed
his identifier to my IdP, he'd have handed it over to me, but there is
no way that he can use MY IdP even though it would make an assertion
about /his/ URL.

> But I agree with you that the delegate identifier might as well just be
> an opaque string per the current spec. This is not inconsistent with my
> post yesterday saying that delegation should be the only case, not a
> special case. There's no disadvantage to this, since the identifier you
> present to your IdP *can* be the same as the one you present to RPs, but
> if delegate is the only mode of operation then it makes the spec simpler
> and thus easier to understand.

I have always thought of the delegate field as implicitly being the
identifier itself when it is not specified. Are you suggesting
requiring a delegate tag?

Josh
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: openid.delegate explained.

[Drummond Reed]

>> Josh Hoyt wrote:
>> 
>> An example to illustrate how delegation can make it hard to understand
>> what's going on:
>> 
>> 1. Set up an IdP that will let me verify, say "bradfitz.com." This
>> does not mean that I have any control of bradfitz.com, just that if I
>> did, I could use this IdP.
>> 
>> 2. Set up an identifier, say "j3h.us" to use "bradfitz.com" as a
>> delegate, and to use my weirdo IdP.
>> 
>> 3. Do authentication of "j3h.us" to a RP, and the messages that go
>> back and forth will be about "bradfitz.com" and the authentication
>> will succeed. The confusing part is that this is the correct
>> behaviour.
>> 
>
>Martin Atkins wrote:
>
>And all you've achieved here is to hand your identifier over to Brad.

I can't tell if you're joking or not, but Josh isn't handing over control of
"bradfitz.com" to Brad. It just means that Josh's weirdo IdP has allowed
Josh to register the identifer "bradfitz.com" in the IdP's namespace. So in
THAT namespace only, that's Josh's identifier. Yes that would be a highly
unadvised IdP policy, but that's the weirdo IdP Josh chose ;-)

>But I agree with you that the delegate identifier might as well just be 
>an opaque string per the current spec. This is not inconsistent with my 
>post yesterday saying that delegation should be the only case, not a 
>special case. There's no disadvantage to this, since the identifier you 
>present to your IdP *can* be the same as the one you present to RPs, but 
>if delegate is the only mode of operation then it makes the spec simpler 
>and thus easier to understand.
>
>(and it no longer needs to be called "delegate", because it doesn't need 
>to be called anything other than "the only way to do it".)

Very interesting observation, Martin. I've spent the last six hours writing
up a fairly exhaustive analysis of this whole issue (both to help close the
issue here, and to help close a closely related issue in XRI Resolution 2.0
Working Draft 11, into which we're incorporating the Yadis spec).

I believe the final analysis may support your conclusion. But it's past
midnight now and since I want to finish it with a clear mind, it will have
to wait until tomorrow morning.

=Drummond 

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs