Re: Summarizing Where We Are

[Dick Hardt]

On 5-Oct-06, at 4:41 PM, Josh Hoyt wrote:

> On 10/5/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
>> I think you missed my message arguing why it was important and that
>> being part of the return_to URL made it hard for the functionality to
>> be contained in the library
>
> I'm not sure I buy this reasoning, since our OpenID 1 libraries add a
> nonce to the return_to URL (which is not hard, since the library needs
> to add stuff to the return_to URL anyway)

curious as to why the RP library needs to add stuff to the return_to  
URL? Does it need to for a OpenID 2.0 call?

>
> That being said, I think it's a quite reasonable parameter.

:)

> I just
> think that this particular argument is bogus.

It could be!

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

Adoption questions

[Chris Drake]

I still worry about end-user experience, privacy, and OpenID
usefulness to RPs running non-trivial services.

Can someone outline how user privacy gets maintained? (and what, if
anything, a user needs to do and/or understand to support this?)

Would any RP handling, say, credit-card data, be comfortable with
adopting the proposed spec?  Think: Amazon, wanting to re-authenticate
upon purchase.

Is my understanding accurate: OpenID is unable to support single sign
on.  If not - lets assume it's 9am.  I just signed on.  I can visit
RP#1 then RP#2 then RP#3 and go back and forth all day without
hindrance, until I next sign off - yes?

Privacy: during any hypothetical overheard lunchtime conversation
between The CEO of RP#1 and the CEO of RP#2 - nobody's ever going to
hear this fragment of conversation: "... yeah - that troublemaker is
one of our users too ..." - or are they?

Sorry to harp on about the fundamentals.  I'm not so sure the
under-hood work is as important as the "big picture", and I don't
think we've got this last bit right yet.

Kind Regards,
Chris Drake,
=1id.com


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

Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

[Dick Hardt]

I like making all identifiers work the same way. The wording around  
directed identity is somewhat confusing. Would be clearer if there  
was a complete description of what happened. ie. complete the  
transaction. In Directed Identity, the RP needs to do discovery on  
the identifier provided to make sure the IdP is authoritative for it.

I think "Token" is not a good name, so many other meanings. Perhaps  
"handle"?

-- Dick

On 4-Oct-06, at 11:34 AM, Martin Atkins wrote:

>
> 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
>
>

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

Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

[Marius Scurtescu]

On 5-Oct-06, at 3:36 PM, Recordon, David wrote:

> Conceptually I think I like this model.  It does seem easier to
> understand.
>
> Other thoughts on this?

I am still not sure how the delegated identifier is useful. I did  
miss the earlier discussions, so probably I don't have enough  
background on this.

The only problem it seems to solve is that of vanity identifiers.  
Switching IdPs where you had an IdP issued identity for the original  
IdP does not seem to be possible, you have no control over that  
original identity so you cannot use it anymore. If you had a vanity  
identity with the original IdP then switching only means pointing  
your vanity identity to the new IdP. So it really boils down to  
controlling your vanity identity.

Instead of dealing with vanity identities using the delegate tag why  
not let the IdP manage your vanity identities? When you register with  
an IdP you should be able to register additional vanity identities,  
as many as you want. You have to prove to the IdP that you control  
them, but this is a different problem (I'll get back to this).

This is similar to domain names (identities) and hosting companies  
(IdPs). You can configure your domain to point to a different hosting  
company (this is like editing your Yadis document to point to another  
IdP). If you don't care about your own domain then you can get cheap  
or free hosting but at some URL controlled by the hosting company  
(these would be the IdP issued identities).

Most of the sites you deal with are RPs, not IdPs. Also, you would  
trust more your IdP then any RP. The link between multiple vanity  
identifiers will be know only to the IdP, the RPs will not know this.

Now, how would the IdP check that you indeed control a vanity  
identity? First of all, you have to point to that IdP. Second, the  
IdP will check that no one else claimed this vanity identity. So  
unless there is an attempt by someone else to claim the same identity  
the IdP can take your word for it. If it wants to go one step further  
(or if there is a conflict) then the IdP can ask you for more proof  
that you own this identity:
- it can send a verification email associated with the domain of this  
identity (if it is a root domain)
- it can ask you to place a special file under this domain/path
- it can ask you to add special headers in the HTML page of this  
identity
- it can ask you to add a special field into the yadis document (and  
this field could be a replacement for the delegate element)

Does this make sense? What am I missing?

Thanks,
Marius


>
> --David
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Martin Atkins
> Sent: Wednesday, October 04, 2006 11:34 AM
> To: specs@openid.net
> Subject: [PROPOSAL] Separate Public Identifier from IdP Identifier
>
>
> 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
>
> ___
> 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: Summarizing Where We Are

[Josh Hoyt]

On 10/5/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
> I think you missed my message arguing why it was important and that
> being part of the return_to URL made it hard for the functionality to
> be contained in the library

I'm not sure I buy this reasoning, since our OpenID 1 libraries add a
nonce to the return_to URL (which is not hard, since the library needs
to add stuff to the return_to URL anyway)

That being said, I think it's a quite reasonable parameter. I just
think that this particular argument is bogus.

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

RE: "Binding" Votes

[Recordon, David]

I'd hope that the authors would pay attention to the larger vote and in
the case where there is disagreement go back over all the reasoning
again and possibly change their opinion.

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Mike Glover
Sent: Thursday, October 05, 2006 4:19 PM
To: specs@openid.net
Subject: Re: "Binding" Votes


  How does this effectively differ from 'only authors get a binding
vote'?  If everyone agrees with the authors, the authors get what they
want.  If they disagree, the authors still get what they want.

-mike

On Thu, 5 Oct 2006 16:09:01 -0700
"Recordon, David" <[EMAIL PROTECTED]> wrote:

> Just to add a little clarity to this.  My proposal is that anyone on 
> this list can have a "binding" vote in all votes.  At the end of the 
> vote, the results will be posted with the votes from the listed 
> authors separated from the total.  If the outcome of the two groups is

> the same, obviously there is a prevalent choice.  If the outcome 
> differs, then it will be up to the authors to make the final decision.
> 
> --David
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Recordon, David
> Sent: Thursday, October 05, 2006 3:33 PM
> To: specs@openid.net
> Subject: "Binding" Votes
> 
> Realized we haven't really decided who has a binding vote for spec 
> proposals.  Up to this point the listed authors have been making all 
> final decisions, but we also didn't have a mailing list like this one 
> with a smaller distribution and technical membership.
> 
> So the question comes up, should only the listed authors (Brad, Josh, 
> Dick, and myself) have binding votes or can the vote of anyone on this

> list be binding?  Up to now I've been counting votes in terms of 
> anyone who votes on this list.
> 
> I don't have a problem continuing down this path until it becomes a 
> problem.  I will however capture vote results broken up between 
> authors and the larger community.  I'd imagine that in most cases the 
> vote result will be the same.  In the case when it isn't, I'd propose 
> we leave it to the authors to further discuss the proposal and 
> reasoning behind both sides, and then ultimately make the final
decision.
> 
> Does that sound alright to everyone?
> 
> --David
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
> 
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
> 
> 
___
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: Summarizing Where We Are

[Recordon, David]

Yeah, I think I did.  Was there another message I missed besides
http://openid.net/pipermail/specs/2006-October/000200.html?

--David 

-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 05, 2006 4:19 PM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: Summarizing Where We Are


On 5-Oct-06, at 3:20 PM, Recordon, David wrote:

>  * Request nonce and name
>   Proposal as a whole has been rejected.  Request nonce can be 
> contained within the "return_to" parameter as the IdP redirects the 
> user-agent back to it upon completion of the request.  Will post vote 
> thread posted to rename openid.nonce to openid.response_nonce.

I think you missed my message arguing why it was important and that
being part of the return_to URL made it hard for the functionality to be
contained in the library



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

Re: "Binding" Votes

[Mike Glover]

  How does this effectively differ from 'only authors get a binding vote'?  If 
everyone agrees with the authors, the authors get what they want.  If they 
disagree, the authors still get what they want.

-mike

On Thu, 5 Oct 2006 16:09:01 -0700
"Recordon, David" <[EMAIL PROTECTED]> wrote:

> Just to add a little clarity to this.  My proposal is that anyone on
> this list can have a "binding" vote in all votes.  At the end of the
> vote, the results will be posted with the votes from the listed authors
> separated from the total.  If the outcome of the two groups is the same,
> obviously there is a prevalent choice.  If the outcome differs, then it
> will be up to the authors to make the final decision.
> 
> --David 
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Recordon, David
> Sent: Thursday, October 05, 2006 3:33 PM
> To: specs@openid.net
> Subject: "Binding" Votes
> 
> Realized we haven't really decided who has a binding vote for spec
> proposals.  Up to this point the listed authors have been making all
> final decisions, but we also didn't have a mailing list like this one
> with a smaller distribution and technical membership.
> 
> So the question comes up, should only the listed authors (Brad, Josh,
> Dick, and myself) have binding votes or can the vote of anyone on this
> list be binding?  Up to now I've been counting votes in terms of anyone
> who votes on this list.
> 
> I don't have a problem continuing down this path until it becomes a
> problem.  I will however capture vote results broken up between authors
> and the larger community.  I'd imagine that in most cases the vote
> result will be the same.  In the case when it isn't, I'd propose we
> leave it to the authors to further discuss the proposal and reasoning
> behind both sides, and then ultimately make the final decision.
> 
> Does that sound alright to everyone?
> 
> --David
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
> 
> ___
> 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: Summarizing Where We Are

[Dick Hardt]

On 5-Oct-06, at 3:20 PM, Recordon, David wrote:

>  * Request nonce and name
>   Proposal as a whole has been rejected.  Request nonce can be
> contained within the "return_to" parameter as the IdP redirects the
> user-agent back to it upon completion of the request.  Will post vote
> thread posted to rename openid.nonce to openid.response_nonce.

I think you missed my message arguing why it was important and that  
being part of the return_to URL made it hard for the functionality to  
be contained in the library


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

RE: "Binding" Votes

[Recordon, David]

Just to add a little clarity to this.  My proposal is that anyone on
this list can have a "binding" vote in all votes.  At the end of the
vote, the results will be posted with the votes from the listed authors
separated from the total.  If the outcome of the two groups is the same,
obviously there is a prevalent choice.  If the outcome differs, then it
will be up to the authors to make the final decision.

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Recordon, David
Sent: Thursday, October 05, 2006 3:33 PM
To: specs@openid.net
Subject: "Binding" Votes

Realized we haven't really decided who has a binding vote for spec
proposals.  Up to this point the listed authors have been making all
final decisions, but we also didn't have a mailing list like this one
with a smaller distribution and technical membership.

So the question comes up, should only the listed authors (Brad, Josh,
Dick, and myself) have binding votes or can the vote of anyone on this
list be binding?  Up to now I've been counting votes in terms of anyone
who votes on this list.

I don't have a problem continuing down this path until it becomes a
problem.  I will however capture vote results broken up between authors
and the larger community.  I'd imagine that in most cases the vote
result will be the same.  In the case when it isn't, I'd propose we
leave it to the authors to further discuss the proposal and reasoning
behind both sides, and then ultimately make the final decision.

Does that sound alright to everyone?

--David
___
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: "Binding" Votes

[Drummond Reed]

+1.

BTW, a suggestion that you can just report votes in future emails as "+'s,
0's, -'s" as that's a little easier to read. For example:

Foo feature +4, 0, -2
Bar feature +3, 2, -3

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Recordon, David
Sent: Thursday, October 05, 2006 3:33 PM
To: specs@openid.net
Subject: "Binding" Votes

Realized we haven't really decided who has a binding vote for spec
proposals.  Up to this point the listed authors have been making all
final decisions, but we also didn't have a mailing list like this one
with a smaller distribution and technical membership.

So the question comes up, should only the listed authors (Brad, Josh,
Dick, and myself) have binding votes or can the vote of anyone on this
list be binding?  Up to now I've been counting votes in terms of anyone
who votes on this list.

I don't have a problem continuing down this path until it becomes a
problem.  I will however capture vote results broken up between authors
and the larger community.  I'd imagine that in most cases the vote
result will be the same.  In the case when it isn't, I'd propose we
leave it to the authors to further discuss the proposal and reasoning
behind both sides, and then ultimately make the final decision.

Does that sound alright to everyone?

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

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

[PROPOSAL] Remove setup_url

[larry drebes]

I'm sorry this proposal did not get put up on the wiki earlier.   Brian
Ellin proposed removing setup_url back in Aug.

http://lists.danga.com/pipermail/yadis/2006-August/002824.html

Here's a copy of the text

A couple of days ago I started working on an immediate mode OpenID
consumer.  I noticed a couple of things that I'd like to get some
feedback on, especially as the OpenID 2.0 spec gets rounded out.

1) The spec 1.x spec doesn't clearly state what the action at
openid.setup_url should do.  Most live openid servers simply generate
a setup_url that switches the openid.mode from checkid_immediate to
checkid_setup, but the behavior of the setup_url isn't described very
clearly in the spec.  As a consumer author I'd like to know what is
going to happen when I send the user off to the setup_url in a new
window.  Will they get redirected back to my site?  Should I display a
message telling them to come back and click "login" again once they
have logged into the server?  It totally depends on what happens at
the setup_url.

2) Since immediate mode requests are usually made from a hidden iframe
in the user's browser, the openid response handler must generate some
_javascript_ which then updates the DOM of the page, or opens a new
window with the setup_url. Since the setup_url uses the return_to of
the immediate mode request, the checkid_setup response (in the new
window, not the hidden iframe) renders the _javascript_ response
intended for the immediate mode response.

It is possible to write _javascript_ which can determine if the response
is from an immediate or setup checkid request, but it involves doing
something which checks for an element that won't exist on the setup
response page.  I don't like this solution:

var div = document.getElementById("immediate_mode_message");
if (div) div.innerHTML = "Logged In";
else window.location = 'http://example.com/logged_in';

The feeling I get after implementing an immediate mode consumer is
that the setup_url is weird and has the potential to introduce
inconsistency.  If all of the servers are just going to generate a
setup_url which is a checkid_setup request, then why not just let the
consumer do it?  When the immediate mode response says that the user
can't be logged in, the consumer could just generate it's own
checkid_setup request using a return_to designed to properly handle
those kinds of requests.  No javscript hacks required.

So, I'd like to see the setup_url described in more detail in the
spec, or tossed out for OpenID 2.0.  Thoughts?

Brian Ellin
JanRain, Inc.



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

RE: [PROPOSAL] Separate Public Identifier from IdP Identifier

[Recordon, David]

Conceptually I think I like this model.  It does seem easier to
understand.

Other thoughts on this?

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Martin Atkins
Sent: Wednesday, October 04, 2006 11:34 AM
To: specs@openid.net
Subject: [PROPOSAL] Separate Public Identifier from IdP Identifier


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

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

"Binding" Votes

[Recordon, David]

Realized we haven't really decided who has a binding vote for spec
proposals.  Up to this point the listed authors have been making all
final decisions, but we also didn't have a mailing list like this one
with a smaller distribution and technical membership.

So the question comes up, should only the listed authors (Brad, Josh,
Dick, and myself) have binding votes or can the vote of anyone on this
list be binding?  Up to now I've been counting votes in terms of anyone
who votes on this list.

I don't have a problem continuing down this path until it becomes a
problem.  I will however capture vote results broken up between authors
and the larger community.  I'd imagine that in most cases the vote
result will be the same.  In the case when it isn't, I'd propose we
leave it to the authors to further discuss the proposal and reasoning
behind both sides, and then ultimately make the final decision.

Does that sound alright to everyone?

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

[VOTE] Rename openid.nonce to openid.response_nonce

[Recordon, David]

Stemming from the proposal to add a request nonce, the idea to rename
the openid.nonce field to openid.response_nonce surfaced.  Is this
something that we should do?

Vote closes Tuesday the 10th at 3:30pm PST.  Votes are +1 (in support of
idea), 0 (abstain), or -1 (disagree).  Traditionally a -1 vote, with
appropriate technical reasoning, will cause the vote as a whole to fail.
In this case, I believe it will be best to make the decision tallying
all votes for and against unless a strong technical argument can be made
for not renaming this parameter.

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

Summarizing Where We Are

[Recordon, David]

Trying to catch up on all the discussion in the past 36 hours.  Been
great to read through it all, really shows the interest and excitement
that we all have in OpenID.  I do however want to rope everyone back in
a bit so we can focus on what is going to be a reality within the Auth
2.0 spec.

I would like to have draft 10 published by next Friday, that gives us
all slightly over a week to finish discussion and make the changes to
the spec itself.  The goal is that draft 10 then becomes used for
implementations and only changes in draft 11 are from problems found via
implementations and general cleanup.

For any proposal that hasn't been accepted, I will post a call for a
formal vote the morning of Tuesday the 10th so that the votes will end
Friday morning.  Please keep in mind that 2.0 will not be the last
version of OpenID Authentication, thus we should not force proposals in
if more discussion is needed.

Here is my current understanding of the status for each proposal:
 * IdP-supported Delegation & Separate Public Identifier from IdP
Identifier
Still being highly discussed with an additional proposal made by
Mart and one by Chris Drake.

 * Rename trust_root to realm
Accepted (4 +1, 1 0, 0 -1)

 * Remove SIGNALL
Accepted (6 +1, 0 0, 0 -1)

 * Standard multivalue parameter mechanism
Current opinion (1 +1, 0 0, 2 -1).  General consensus is that
this should not be a requirement of the specification itself, rather as
part of each extension where this becomes needed.  Differing extensions
may have differing requirements for delimiters.

 * Request nonce and name
Proposal as a whole has been rejected.  Request nonce can be
contained within the "return_to" parameter as the IdP redirects the
user-agent back to it upon completion of the request.  Will post vote
thread posted to rename openid.nonce to openid.response_nonce.

 * Authentication age
Still being highly discussed.

 * bare response / bare request
Still being discussed


Cool? Cool!

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

RE: [PROPOSAL] authentication age

[Recordon, David]

I don't see a problem with the wording of:
In the spec, I would say auth age is a request the RP MAY make, and that
the IdP SHOULD accept, and that there is no certainty that the IdP will
accept it.

I don't think however that enough consensus will be reached on this
proposal to place it in the spec though.  That is why I'd advise it be
written as an extension and then merged into the specification in a
future version.

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dick Hardt
Sent: Thursday, October 05, 2006 9:25 AM
To: Kevin Turner
Cc: specs@openid.net
Subject: Re: [PROPOSAL] authentication age

Kevin, thanks for the well articulated argument.

I do see this as something that is completely within the End Users
control, and if the End User chose to ignore it, then that is their
choice.

The use case is that for convenience, a site wants to let the user do
certain functions without having to have authenticated recently. Some
functions require a fresh authentication. For example it is easy to
browse around Amazon.com, but when you go to purchase something, they
want to make sure that it is still you, and prompt you for your
password. Of course I can have my browser configured to autocomplete the
password prompt and all I have to do is press enter, which circumvents
proving it is me since someone walking up to my computer does not need
to know my password to complete a purchase.

The point is that the Amazon.com has made an effort to increase the
certainty that it is me, and it is my choice to not take advantage of
it. If OpenID does NOT have this functionality, sites that have
requirements similar to Amazon.com will be reluctant to adopt OpenID.

In the spec, I would say auth age is a request the RP MAY make, and that
the IdP SHOULD accept, and that there is no certainty that the IdP will
accept it.

To look at it another way, there is no requirement for the IdP to ask me
if I want to respond to an RP that I have never been to before. I could
have an IdP that responds positively to ever request with no interaction
from myself. There is nothing in OpenID that proves I approved the
request, or for that matter that there is actually a person at the end
of the browser.


On 4-Oct-06, at 6:29 PM, Kevin Turner wrote:

> 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
>
>

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

___
specs mailing list

RE: Re[2]: Strong Authencation (was [PROPOSAL] authentication age

[Drummond Reed]

Chris,

Great examples. Signed credentials makes lots of sense. OpenID AuthN 2.0
doesn't handle them yet but I can completely understand them in the roadmap.

=Drummond 

-Original Message-
From: Chris Drake [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 05, 2006 10:51 AM
To: Drummond Reed
Cc: specs@openid.net
Subject: Re[2]: Strong Authencation (was [PROPOSAL] authentication age

Hi Drummond,

Example1: RSA would provide a signed response indicating that the user
correctly entered the SecurID token code.

Example2: The RP would have the public key of the company that
supplies the fingerprint scanning hardware (although some extra
thought as to how a fingerprint ultimately matches to an Identity is
required, which will need an entirely different information flow to
Example1).

Is Dick a vendor himself? he no doubt knows other ways.

Kind Regards,
Chris Drake,
=1id.com


Friday, October 6, 2006, 3:19:44 AM, you wrote:

DR> Dick,

DR> You say, " The strong authentication will be supplied by a vendor that
has
DR> been certified to provide standardized levels of authentication. The IdP
DR> will often NOT be the strong auth vendor."

DR> Can you explain how this might work, i.e., how can the RP have a
DR> relationship directly with the strong auth vendor and not the IdP? Would
the
DR> IdP be outsourcing authentication to the strong auth vendor? In which
case,
DR> isn't the strong auth vendor the IdP?

DR> =Drummond 

DR> -Original Message-
DR> From: [EMAIL PROTECTED]
DR> [mailto:[EMAIL PROTECTED] On Behalf
DR> Of Dick Hardt
DR> Sent: Thursday, October 05, 2006 9:36 AM
DR> To: Gabe Wachob
DR> Cc: specs@openid.net
DR> Subject: Strong Authencation (was [PROPOSAL] authentication age

DR> The vision I have is that strong authentication to your IdP will be
DR> common in the future.

DR> The strong authentication will be supplied by a vendor that has been
DR> certified to provide standardized levels of authentication. The IdP
DR> will often NOT be the strong auth vendor.

DR> The RP will have a trust relationship with the vendor, likely through
DR> a vendor consortium that delegates to vendors that their product is
DR> certified, ie. the RP will not need to trust each vendor, just the
DR> certification body.

DR> I would hope that OpenID can be extended over time to be able to move
DR> around these types of strong auth assertions.

DR> -- Dick


DR> On 4-Oct-06, at 8:41 PM, Gabe Wachob wrote:

>> 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
>>
>>

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

Re[2]: Strong Authencation (was [PROPOSAL] authentication age

[Chris Drake]

Hi Drummond,

Example1: RSA would provide a signed response indicating that the user
correctly entered the SecurID token code.

Example2: The RP would have the public key of the company that
supplies the fingerprint scanning hardware (although some extra
thought as to how a fingerprint ultimately matches to an Identity is
required, which will need an entirely different information flow to
Example1).

Is Dick a vendor himself? he no doubt knows other ways.

Kind Regards,
Chris Drake,
=1id.com


Friday, October 6, 2006, 3:19:44 AM, you wrote:

DR> Dick,

DR> You say, " The strong authentication will be supplied by a vendor that has
DR> been certified to provide standardized levels of authentication. The IdP
DR> will often NOT be the strong auth vendor."

DR> Can you explain how this might work, i.e., how can the RP have a
DR> relationship directly with the strong auth vendor and not the IdP? Would the
DR> IdP be outsourcing authentication to the strong auth vendor? In which case,
DR> isn't the strong auth vendor the IdP?

DR> =Drummond 

DR> -Original Message-
DR> From: [EMAIL PROTECTED]
DR> [mailto:[EMAIL PROTECTED] On Behalf
DR> Of Dick Hardt
DR> Sent: Thursday, October 05, 2006 9:36 AM
DR> To: Gabe Wachob
DR> Cc: specs@openid.net
DR> Subject: Strong Authencation (was [PROPOSAL] authentication age

DR> The vision I have is that strong authentication to your IdP will be
DR> common in the future.

DR> The strong authentication will be supplied by a vendor that has been
DR> certified to provide standardized levels of authentication. The IdP
DR> will often NOT be the strong auth vendor.

DR> The RP will have a trust relationship with the vendor, likely through
DR> a vendor consortium that delegates to vendors that their product is
DR> certified, ie. the RP will not need to trust each vendor, just the
DR> certification body.

DR> I would hope that OpenID can be extended over time to be able to move
DR> around these types of strong auth assertions.

DR> -- Dick


DR> On 4-Oct-06, at 8:41 PM, Gabe Wachob wrote:

>> 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
>>
>>

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

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



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

Re[2]: [PROPOSAL] authentication age

[Kevin Turner]

On Thu, 2006-10-05 at 13:25 +1000, Chris Drake wrote:
> 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?

Woah, slow down there.  I won't say this is completely crazy talk, but I
want to be careful about what words are put in my mouth.  ;)  

The description that introduced a lot of people to OpenID was "a
decentralized identity system, but one that's actually decentralized and
doesn't entirely crumble if one company turns evil or goes out of
business."

I think systems with root authorities are prone to crumbling if the root
authority turns evil or goes out of business.

Furthermore, the "it's easy to switch IdPs; it's easy to run your own
IdP" property is very important to OpenID.  This goes away if there's a
root authority you have to be audited/verified by before anyone will
talk to you.

There's my word of caution for now.  Gabe and Dick have both said some
good things about how to consider these issues now and going forward.


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

RE: Strong Authencation (was [PROPOSAL] authentication age

[Gabe Wachob]

I don't think it will get ugly because I think there are many ways to layer
on the functionality we are talking about. 

For example, Visa has something called 3-D Secure which is similar in many
ways to OpenID using INames. Instead of keying authentication off of INames,
they use Credit Card numbers. 

3-D Secure is implemented in one of several programs - Visa has "Verified by
Visa", Mastercard has "Securecode". Each of these programs varies the
protocol slightly, but by in large, the authentication mechanisms are
enforced by *policy* (ie you MUST use auth at least as strong as this) and
that policy is enforced (among several methods) by 1) the fact that
communication with the (credit card) directory requires clients to
authenticate *to the directory* and 2) the back channel communication is
mediated through the directory. That is one mechanism (which I really don't
recommend) that OpenID could take. 

Dick suggested a method where there is some vendor providing strong
authentication which is verifiable by anyone (or at least anyone who is part
of the club and cares). That authentication proof could ride along as an
extension element in OpenID. I suggested another approach where IDP's
themselves were "part of a club" (and there could be any number of clubs)
and that proof that the *IDP* was part of the club could come along as an
extension to the OpenID data. 

And if you are worried about how the RP knows ahead of time that an IDP can
provide the requisite extensions, we have a mechanism in the XRDS to
advertise these facts. 

So I think all these pieces are there -- it's just a matter of figuring out
how to put them together for the specific scenarios we have. I think in fact
that there will not be *one* answer, but several -- each based on the
ecosystem involved. If electronic payments systems ever use OpenID, there
will be certain controls that everyone who is participating will have to
agree to, and those controls may have to be enforceable and auditable by
multiple parties. In other scenarios, only certain parties may care (ie
RP's) and it may be untenable to impose as many extension pieces.

But I think we're getting ahead of ourselves. As long as you believe the
extensibility is in there and there is a reasonable path forward, then we
should get the basic infrastructure gelled and rolled out soon, or else
we'll never get the experience and mindshare with OpenID that we want. 

The quicker we get today done, the quicker we can get to tomorrow. 

-Gabe


> -Original Message-
> From: Chris Drake [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 05, 2006 10:22 AM
> To: Dick Hardt
> Cc: Gabe Wachob; 'Kevin Turner'; specs@openid.net
> Subject: Re: Strong Authencation (was [PROPOSAL] authentication age
> 
> Hi All,
> 
> 1. Amazon asks the IdP "Please assert this user is not a Robot"
>How can it trust this occurred?
> 
> 2. Amazon asks the IdP "Please re-authenticate this user, via
>two-factor, two-way strong authentication"
>How can it trust *this* occurred?
> 
> The IdP can *say* it did, but would RPs prefer a "stronger" role to
> encourage adoption? (eg: #1 - the RP provides the captcha, and the
> hash of the solution, while the IdP returns the solution, or #2 - the
> RP provides a nonce and later looks for this nonce in the IdP's
> also-signed-by-the-authentication-vendor-technology response)
> 
> i.e.: It might get ugly to try and add this stuff in later if we've
> not catered up-front for these kinds of interchanges.
> 
> Kind Regards,
> Chris Drake

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

Re: Strong Authencation (was [PROPOSAL] authentication age

[Chris Drake]

Hi All,

1. Amazon asks the IdP "Please assert this user is not a Robot"
   How can it trust this occurred?

2. Amazon asks the IdP "Please re-authenticate this user, via
   two-factor, two-way strong authentication"
   How can it trust *this* occurred?

The IdP can *say* it did, but would RPs prefer a "stronger" role to
encourage adoption? (eg: #1 - the RP provides the captcha, and the
hash of the solution, while the IdP returns the solution, or #2 - the
RP provides a nonce and later looks for this nonce in the IdP's
also-signed-by-the-authentication-vendor-technology response)

i.e.: It might get ugly to try and add this stuff in later if we've
not catered up-front for these kinds of interchanges.

Kind Regards,
Chris Drake

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

RE: Strong Authencation (was [PROPOSAL] authentication age

[Drummond Reed]

Dick,

You say, " The strong authentication will be supplied by a vendor that has
been certified to provide standardized levels of authentication. The IdP  
will often NOT be the strong auth vendor."

Can you explain how this might work, i.e., how can the RP have a
relationship directly with the strong auth vendor and not the IdP? Would the
IdP be outsourcing authentication to the strong auth vendor? In which case,
isn't the strong auth vendor the IdP?

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Dick Hardt
Sent: Thursday, October 05, 2006 9:36 AM
To: Gabe Wachob
Cc: specs@openid.net
Subject: Strong Authencation (was [PROPOSAL] authentication age

The vision I have is that strong authentication to your IdP will be  
common in the future.

The strong authentication will be supplied by a vendor that has been  
certified to provide standardized levels of authentication. The IdP  
will often NOT be the strong auth vendor.

The RP will have a trust relationship with the vendor, likely through  
a vendor consortium that delegates to vendors that their product is  
certified, ie. the RP will not need to trust each vendor, just the  
certification body.

I would hope that OpenID can be extended over time to be able to move  
around these types of strong auth assertions.

-- Dick


On 4-Oct-06, at 8:41 PM, Gabe Wachob wrote:

> 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
>
>

___
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: Strong Authencation (was [PROPOSAL] authentication age

[Dick Hardt]

Hi Gabe

Agreed that things like strong auth would be extensions.

I still think auth_age is something that RPs expect to be able to  
influence (primarily being able to ask for the auth ceremony to be  
performed) and should be in the current spec.

-- Dick

On 5-Oct-06, at 9:47 AM, Gabe Wachob wrote:

> Dick
>   That's sounds like a reasonable approach (if I understand what you
> are saying), and frankly one I hadn't considered.
>   More importantly, it sounds like we agree that we expect this to lie
> in the domain of OpenID extensions and that we don't need to  
> consider these
> scenarios/requirements now for the 2.0 specs?
>
>   -Gabe
>
>> -Original Message-
>> From: Dick Hardt [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, October 05, 2006 9:36 AM
>> To: Gabe Wachob
>> Cc: 'Chris Drake'; 'Kevin Turner'; specs@openid.net
>> Subject: Strong Authencation (was [PROPOSAL] authentication age
>>
>> The vision I have is that strong authentication to your IdP will be
>> common in the future.
>>
>> The strong authentication will be supplied by a vendor that has been
>> certified to provide standardized levels of authentication. The IdP
>> will often NOT be the strong auth vendor.
>>
>> The RP will have a trust relationship with the vendor, likely through
>> a vendor consortium that delegates to vendors that their product is
>> certified, ie. the RP will not need to trust each vendor, just the
>> certification body.
>>
>> I would hope that OpenID can be extended over time to be able to move
>> around these types of strong auth assertions.
>>
>> -- Dick
>>
>>
>> On 4-Oct-06, at 8:41 PM, Gabe Wachob wrote:
>>
>>> 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
>>>
>>>
>
>

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

RE: Strong Authencation (was [PROPOSAL] authentication age

[Gabe Wachob]

Dick
That's sounds like a reasonable approach (if I understand what you
are saying), and frankly one I hadn't considered.
More importantly, it sounds like we agree that we expect this to lie
in the domain of OpenID extensions and that we don't need to consider these
scenarios/requirements now for the 2.0 specs?

-Gabe

> -Original Message-
> From: Dick Hardt [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 05, 2006 9:36 AM
> To: Gabe Wachob
> Cc: 'Chris Drake'; 'Kevin Turner'; specs@openid.net
> Subject: Strong Authencation (was [PROPOSAL] authentication age
> 
> The vision I have is that strong authentication to your IdP will be
> common in the future.
> 
> The strong authentication will be supplied by a vendor that has been
> certified to provide standardized levels of authentication. The IdP
> will often NOT be the strong auth vendor.
> 
> The RP will have a trust relationship with the vendor, likely through
> a vendor consortium that delegates to vendors that their product is
> certified, ie. the RP will not need to trust each vendor, just the
> certification body.
> 
> I would hope that OpenID can be extended over time to be able to move
> around these types of strong auth assertions.
> 
> -- Dick
> 
> 
> On 4-Oct-06, at 8:41 PM, Gabe Wachob wrote:
> 
> > 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
> >
> >

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

Strong Authencation (was [PROPOSAL] authentication age

[Dick Hardt]

The vision I have is that strong authentication to your IdP will be  
common in the future.

The strong authentication will be supplied by a vendor that has been  
certified to provide standardized levels of authentication. The IdP  
will often NOT be the strong auth vendor.

The RP will have a trust relationship with the vendor, likely through  
a vendor consortium that delegates to vendors that their product is  
certified, ie. the RP will not need to trust each vendor, just the  
certification body.

I would hope that OpenID can be extended over time to be able to move  
around these types of strong auth assertions.

-- Dick


On 4-Oct-06, at 8:41 PM, Gabe Wachob wrote:

> 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
>
>

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

Re: [PROPOSAL] authentication age

[Dick Hardt]

Kevin, thanks for the well articulated argument.

I do see this as something that is completely within the End Users  
control, and if the End User chose to ignore it, then that is their  
choice.

The use case is that for convenience, a site wants to let the user do  
certain functions without having to have authenticated recently. Some  
functions require a fresh authentication. For example it is easy to  
browse around Amazon.com, but when you go to purchase something, they  
want to make sure that it is still you, and prompt you for your  
password. Of course I can have my browser configured to autocomplete  
the password prompt and all I have to do is press enter, which  
circumvents proving it is me since someone walking up to my computer  
does not need to know my password to
complete a purchase.

The point is that the Amazon.com has made an effort to increase the  
certainty that it is me, and it is my choice to not take advantage of  
it. If OpenID does NOT have this functionality, sites that have  
requirements similar to Amazon.com will be reluctant to adopt OpenID.

In the spec, I would say auth age is a request the RP MAY make, and  
that the IdP SHOULD accept, and that there is no certainty that the  
IdP will accept it.

To look at it another way, there is no requirement for the IdP to ask  
me if I want to respond to an RP that I have never been to before. I  
could have an IdP that responds positively to ever request with no  
interaction from myself. There is nothing in OpenID that proves I  
approved the request, or for that matter that there is actually a  
person at the end of the browser.


On 4-Oct-06, at 6:29 PM, Kevin Turner wrote:

> 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
>
>

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