Re: Proposal: An anti-phishing compromise

[john kemp]

Josh Hoyt wrote:
> On 2/2/07, john kemp <[EMAIL PROTECTED]> wrote:
>> Don't get me wrong - I think it's a good idea for the OP to make a
>> statement about the authentication method used (although I would prefer
>> it to say something like
>> authn_method="urn:openid:2.0:aqe:method:password", rather than
>> phishable="yes"). That points to AQE, as David mentioned already.
> 
> A browser plug-in, like sxipper, that uses a username and (a
> generated, non-user-visible) password internally and will only submit
> it to the correct OP can't be phished.
> 
> Is this a different kind of authentication than "password"? I don't
> think so. Is it phishable? I think that the OP can reasonably say that
> it is not. Therefore, I think that the authentication mechanism is (or
> at least can be) independent from whether the authentication channel
> is phishable.

I will agree that the authentication channel might be separated from the
authentication method, as you have described those concepts. I'm not
sure if that's a meaningful distinction.

For example - in Sxipper, does the password get moved across the network
to the OP, or does Sxipper act as the OP (on the client side?) If the
former, then I'd argue that Sxipper password auth is slightly less
phishable, but not completely so. If the latter, then the trust is
/really/ only between the RP and the user.

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

Re: Proposal: An anti-phishing compromise

[john kemp]

Johnny Bufu wrote:
> On 2-Feb-07, at 12:25 PM, john kemp wrote:
>>> If the authentication mechanism is phishable, a good OP is  
>>> supposed to
>>> say "phishable=yes". Otherwise it is cheating the user's trust.
>> Yes, RPs will just have to trust assertions from an OP. But with  
>> all due
>> respect, I just don't see how "the honour system" mitigates phishing.
> 
> I guess we could argue about where we see the trust.

I guess we could, but I doubt that would be very fruitful for either of
us ;)

> I see it between  
> between the user and the OP. The RP only "trusts" (or rather accepts)  
> the user's choice of an OP (and the assertions coming from it as  
> representing the user).

How about we focus on the proposal at hand?

i) I think that it is a good idea to make some statement from the OP
about the authentication method. Personally I would prefer something
about the authentication method actually used, a la AQE.

It would then be more apparent that the RP still has to make up its own
mind about whether to accept the assertion, rather than simply trusting
in the OP not to lie about whether the method is phishable.

ii) I think adding security considerations in the actual specification,
along the lines that Josh wrote in his original proposal would be a very
good addition.

An acknowledgment that there is the potential for this attack (among
others), and a statement of possible mitigating factors would seem to be
very important when RPs and OPs go to implement the specification.

I believe that security considerations should be in the actual
specification, not simply posted on the wiki, as there is a greater
chance of an implementor reading them if they are with the core protocol
spec.

Regards,

- John

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

Re: Proposal: An anti-phishing compromise

[john kemp]

Johnny Bufu wrote:
> 
> On 2-Feb-07, at 12:04 PM, john kemp wrote:
>> Johnny Bufu wrote:
>>>> If the OP has stolen the user's credentials, it can just say
>>>> "phishable
>>>> = no" and pass its assertion regarding those credentials to the RP.
>>>
>>> And the RP (being now a legitimate one), will perform verification on
>>> the assertion and will fail as it is not coming from the legitimate /
>>> authoritative OP.
>>
>> Sure, but then the (former) rogue OP will take the user's credentials
>> and log in, as the user, at the user's real OP (which will be
>> authoritative). The OP will assert that the user is logged in, and that
>> the credentials weren't phished.
> 
> Then the real OP is obviously wrong, since the authentication was phished.
> 
> If the authentication mechanism is phishable, a good OP is supposed to
> say "phishable=yes". Otherwise it is cheating the user's trust.

Yes, RPs will just have to trust assertions from an OP. But with all due
respect, I just don't see how "the honour system" mitigates phishing.

> 
>>> Since the "rogue OP" is not authoritative for the phished user at any
>>> other RP, I rather see it as an extension of the rogue RP; it's
>>> basically the rogue RP that's proxying the output from the legitimate
>>> OP, so in a sense there's no real "rogue OP".
>>
>> Yes, I see your point, but after the OP is no longer rogue (is "just a
>> user"), it has both the user's OpenID and her credentials.
> 
> But it won't be able to login to RPs that enforce "phishable=no", since
> the assertions will be coming from the real OP (which should say
> "phishable=yes").

Don't get me wrong - I think it's a good idea for the OP to make a
statement about the authentication method used (although I would prefer
it to say something like
authn_method="urn:openid:2.0:aqe:method:password", rather than
phishable="yes"). That points to AQE, as David mentioned already.

Regards,

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

Re: Proposal: An anti-phishing compromise

[john kemp]

Johnny Bufu wrote:

...

>>
>> If the OP has stolen the user's credentials, it can just say  
>> "phishable
>> = no" and pass its assertion regarding those credentials to the RP.
> 
> And the RP (being now a legitimate one), will perform verification on  
> the assertion and will fail as it is not coming from the legitimate /  
> authoritative OP.

Sure, but then the (former) rogue OP will take the user's credentials
and log in, as the user, at the user's real OP (which will be
authoritative). The OP will assert that the user is logged in, and that
the credentials weren't phished.

> 
...

> Since the "rogue OP" is not authoritative for the phished user at any  
> other RP, I rather see it as an extension of the rogue RP; it's  
> basically the rogue RP that's proxying the output from the legitimate  
> OP, so in a sense there's no real "rogue OP".

Yes, I see your point, but after the OP is no longer rogue (is "just a
user"), it has both the user's OpenID and her credentials.

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

Re: Proposal: An anti-phishing compromise

[john kemp]

Johnny Bufu wrote:
> 
> On 2-Feb-07, at 7:05 AM, George Fletcher wrote:
>> but I'm still not sure how this helps with the phishing problem.  As
>> you pointed out John, the issue is a rogue RP redirecting to a rogue
>> OP.  So the rogue OP just steals the credentials and returns whatever
>> it wants.
> 
> In this case, the rogue RP is not interested at in the the auth response
> from the rogue OP (or for that matter from the legitimate OP); just in
> stealing the  user's credentials.
> 
> The phishing field prevents the phisher to later use these credentials
> on a legitimate RP (which will be contacting the legitimate OP) to
> impersonate the user -- if the RP enforces "phishable = no".

I guess I'm confused by the above.

If the OP has stolen the user's credentials, it can just say "phishable
= no" and pass its assertion regarding those credentials to the RP. This
is about a rogue OP, and the relationship between the OP and the user,
not really about the relationship between the OP and RP (although if the
RP knew whether or not it could trust the OP by some out-of-band means,
it would simply not accept an assertion from the OP unless that trust
was established).

You might use a rogue RP to start the attack, but the attack is actually
performed by the rogue OP, not the rogue RP.

- John

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

Re: Proposal: An anti-phishing compromise

[john kemp]

Hi Josh,

In addition to the protocol parameter that you have proposed, I'd hope
that we can add something like what you wrote below as part of the
security considerations section of the OpenID 2.0 Auth specification, as
this text seems to capture quite succinctly the issues that RPs and OPs
should be thinking about when attempting to deal with phishing:

Josh Hoyt wrote:

> The ways that OpenID can potentially make phishing worse:
> 
>  * Redirects to your provider are a fundamental part of the flow of
> OpenID, so being redirected to a phishing site is easy to miss
> 
>  * Every relying party (necessarily) needs to know who the provider
> is in order to verify the authentication response. This means that the
> site knows what UI it needs to use to phish (and even worse, it can
> just proxy the user to the provider)
> 
> I think these two issues cover what makes phishing potentially a
> greater threat when using OpenID.
> 
> Although these problems are significant, if a user can authenticate to
> their OpenID provider through an "non-phishable" mechanism, OpenID can
> make the phishing problem *less* of a threat, because there are fewer
> places that will need to ask for credentials.
> 
> Other relevant issues:
> 
>   * There is no universally deployed solution to the phishing problem
> 
>   * There is not even a universally *accepted* solution to the phishing 
> problem
> 
>   * Any technology that prevents phishing will require user-agent
> support or else will fundamentally change the flow of OpenID (prevent
> relying-party-initiated sign-in)
> 
>   * OpenID is intended to be deployed without requiring specific
> technologies to be present in the user-agent

It might also be helpful to add somewhere a specific definition of
phishing, and the associated attack - that an OP can steal a user's
credentials if they are passed to the OP. Mitigation can only really be
performed by applying client-side changes that ensure that long-lived
private information shared only between the OP and the user (such as a
password) does not pass across the network.

Regards,

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

Re: Proposal: An anti-phishing compromise

[john kemp]

Recordon, David wrote:
> I think we all agree that talking about the method used is far more
> useful, though with this proposal we're really trying to balance it with
> simplicity in the authentication protocol itself.  Maybe it is better to
> phrase the discussion around if the user provided a secret (password) to
> the OP or not to authenticate versus talking about phishing directly.?.

If you were to define a URI for common "authentication method" values,
could this value not be returned, simply, in the protocol?

> 
> I'd hope that this parameter in the auth spec really helps bring the
> discussion around to the Assertion Quality Extension and that it be
> implemented to provide the more robust metadata such as what type of
> authentication was actually preformed.

Agreed. If AQE is not mandated, however, I think that the original idea
of allowing the OP to make a statement about the authentication method
in the actual protocol is still a good one.

If you start with a simple URI, returned directly in the protocol, can
this not be linked to the equivalent statement in the AQE specification?

- John

> 
> --David 
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of john kemp
> Sent: Thursday, February 01, 2007 7:13 PM
> To: Granqvist, Hans
> Cc: OpenID specs list
> Subject: Re: Proposal: An anti-phishing compromise
> 
> Granqvist, Hans wrote:
> 
>>> Proposed Change
>>> ===
>>>
>>> Add a single, required, boolean field to the authentication response 
>>> that specifies whether or not the method the OP used to authenticate 
>>> the user is phishable. The specification will have to provide 
>>> guidelines on what properties an authentication mechanism needs to 
>>> have in order to be "non-phishable." The field is just meant to 
>>> indicate that the authentication mechanism that was used is not a 
>>> standard "secret entered into a Web form."
>> The receiver should decide what is 'non-phishable', not the sender, so
> 
>> it would be better if the OP just states what mechanism was used, 
>> perhaps.
> 
> Agreed. A statement as to the "phishability" or not seems to be too
> vague to be useful. A simple statement of the authentication method used
> would seem to give the same effect, while providing potentially useful
> information (assuming the RP trusts statements from the OP at all.)
> 
>>
>>> Benefits
>>> 
> 
> ...
> 
>> Here's what I think:
>>
>> Since the association step is hardly ever used, it can much more 
>> easily be overloaded with extra information without breaking any 
>> implementation.
>>
>> If the OP would *require* an OpenID association step from the RP, then
> 
>> this step can include an exchange of meta-information between OP and 
>> RP.
> 
> How does the association step between OP and RP change the relationship
> between the OP and the user (agent)?
> 
> I thought the attack we were considering is when a rogue RP directs the
> user agent to a rogue OP, who then steals the user's credentials? How is
> that affected by the rogue RP and rogue OP "associating"?
> 
> - John
> ___
> 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: An anti-phishing compromise

[john kemp]

Granqvist, Hans wrote:

>> Proposed Change
>> ===
>>
>> Add a single, required, boolean field to the authentication 
>> response that specifies whether or not the method the OP used 
>> to authenticate the user is phishable. The specification will 
>> have to provide guidelines on what properties an 
>> authentication mechanism needs to have in order to be 
>> "non-phishable." The field is just meant to indicate that the 
>> authentication mechanism that was used is not a standard 
>> "secret entered into a Web form."
> 
> The receiver should decide what is 'non-phishable', not the 
> sender, so it would be better if the OP just states what 
> mechanism was used, perhaps.

Agreed. A statement as to the "phishability" or not seems to be too
vague to be useful. A simple statement of the authentication method used
would seem to give the same effect, while providing potentially useful
information (assuming the RP trusts statements from the OP at all.)

> 
> 
>> Benefits
>> 

...

> Here's what I think:
> 
> Since the association step is hardly ever used, it can 
> much more easily be overloaded with extra information without
> breaking any implementation.
> 
> If the OP would *require* an OpenID association step from the 
> RP, then this step can include an exchange of meta-information
> between OP and RP. 

How does the association step between OP and RP change the relationship
between the OP and the user (agent)?

I thought the attack we were considering is when a rogue RP directs the
user agent to a rogue OP, who then steals the user's credentials? How is
that affected by the rogue RP and rogue OP "associating"?

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

Re: OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP)

[John Kemp]

Dick Hardt wrote:
>>
>> But why deprecate support for redirects? I'd (still) like to see OpenID
>> implementations that do support browsers without JS turned on .
> 
> 
> As stated a number of times, because the payload is not big enough with
> GET redirects. It is with JS POST redirects.
> 
> OpenID 1.1 did not have a large payload. We expect the payloads to be
> much larger with OpenID 2.0.

I guess the payload size will vary according to the RP and IdP
implementations, no?

> 
> We will see if the JS requirement is an issue. I do not think it is
> given what I know now.

Well, admittedly, if no-one except me thinks that redirects should be
supported in OpenID 2.0, then I certainly expect to lose that argument ;)

Cheers,

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

Re: OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP)

[John Kemp]

Dick Hardt wrote:
> 
> On 18-Nov-06, at 1:56 PM, John Kemp wrote:
> 
>>> It is mentioned that the two methods may be composed, but I still don't
>>> see how the POST form submission can be automated (without JavaScript).
>>> Have I missed that part?
>>
>> My point is that an implementation can offer BOTH profiles, and in cases
>> where it's likely that the browser cannot do JS, it's possible for the
>> RP to attempt one instead of another. Again, this is about being
>> tolerant of different browsers.
> 
> The POST methods meets all the requirements with a degradation in user
> experience for browsers without JS.
> If the user is running a browser without JS, then lots of other sites
> will not work well given the proliferation of JS in sites.
> This also keeps it simple for the RP since it is not having to guess
> what the user agent can do.
> 
> We weighed all the options and moving to POST was the decision. I have
> not seen any new data that would lead me to change my position.

But why deprecate support for redirects? I'd (still) like to see OpenID
implementations that do support browsers without JS turned on .

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

Re: OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP)

[John Kemp]

Johnny Bufu wrote:
> 
>> My point is still that in general, implementations should be tolerant of
>> limited user-agents, and that means supporting functionality that
>> doesn't require JS.
> 
> JS is not required; this is stated in the third paragraph of the
> 'Abstract' section.
> 
> The 'HTML FORM Redirection' section says that "Form submission MAY be
> automated using JavaScript".

And the alternative is for the user to press the 'submit' button. I'd
hope we can allow for implementations to avoid that, by offering a
redirect option.

> 
>>> I see that the "MUST NOT automatically" applies to all redirects:
>>> 301, 302, 303 and 307 (sections 10.3.2, 10.3.3, 10.3.4, and 10.3.8 of
>>> RFC2616).
>>>
>> Agreed. I'm not sure how many user-agents actually comply with this rule
>> though, as POSTed redirects seem in general quite common, and in my
>> experience anyway, seem to take place without my being asked whether I
>> want to accept the redirect.
> 
> Still, we wouldn't want to architect a piece of the protocol to rely on
> the non-conformance of other players with the HTTP protocol, no?

No, you're right about that. We'd want to architect a piece of protocol
that provides a good user experience for as many user-agents as possible.

> I read the HTTP Redirect binding and HTTP POST Binding sections in the
> document you referenced.
> 
> - The HTTP Redirect Binding passes the parameters around encoded in the
> redirect URL (subject to size limitations), similar to OpenID's HTTP
> redirect + GET method.
> 
> - The HTTP POST Binding uses HTML forms to pass the data (again similar
> to OpenID's HTML FORM Redirection). Furthermore, the example from the
> HTTP POST Binding contains the following:
> 
> Note: Since your browser does not support JavaScript,
> you must press the Continue button once to proceed.
> 
> It is mentioned that the two methods may be composed, but I still don't
> see how the POST form submission can be automated (without JavaScript).
> Have I missed that part?

My point is that an implementation can offer BOTH profiles, and in cases
where it's likely that the browser cannot do JS, it's possible for the
RP to attempt one instead of another. Again, this is about being
tolerant of different browsers.

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

Re: OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP)

[John Kemp]

Hello,

Although I agree with you about the contents of RFC2616, I don't see why
there is a need to restrict OpenID to requiring POSTs of HTML forms.

It's both reasonable to have a redirect profile with HTTP GET
(especially if it's possible to restrict the message size by specifying
a minimum required message that will suffice) and also to have a HTTP
POST redirect method (see SAML 2.0 HTTP POST/Redirect bindings [1] for
one that is deployed). It's also possible to determine from the
user-agent string whether you're working with a limited browser, and
should use one thing or another.

My point is still that in general, implementations should be tolerant of
limited user-agents, and that means supporting functionality that
doesn't require JS.

More specific comments are inline below:

Regards,

- John

[1]
http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf
(PDF) 

Johnny Bufu wrote:
> On 17-Nov-06, at 7:17 PM, John Kemp wrote:
>   
>>> - According to the HTTP RFC, user agents receiving a 3XX redirect in
>>> response to a POST request MUST NOT automatically redirect the  
>>> request.
>>>   
>> Yup, if you use a 302 redirect, which is probably what you'd want,  
>> then
>> there is that potential. You can use 303 or 307 (as mentioned in 5.2.1
>> of draft 10 of the spec.) in order to better control that.
>> 
>
> I see that the "MUST NOT automatically" applies to all redirects:  
> 301, 302, 303 and 307 (sections 10.3.2, 10.3.3, 10.3.4, and 10.3.8 of  
> RFC2616).
>   
Agreed. I'm not sure how many user-agents actually comply with this rule
though, as POSTed redirects seem in general quite common, and in my
experience anyway, seem to take place without my being asked whether I
want to accept the redirect.
>   
>>> - See the note in RFC: even though the user-agents aren't supposed to
>>> change the method, some perform a GET on the redirect URL, even  
>>> though
>>> the initial request was a POST.
>>>
>>> - In the specific case of OpenID authentication messages, the server
>>> issuing the redirect needs to send data (the OpenID message) to its
>>> peer, via the user agent. I don't see how the user-agent can be
>>> instructed via a redirect to use the POST response at the redirect  
>>> URL.
>>>   
>> Wouldn't the IdP would issue also a 302 redirect with its response
>> message to the RP?
>> 
>
> Not to the RP directly; the user-agent would receive the IdP's  
> response, but it wouldn't have a way of POSTing it to the RP.
>
> (The same applies to auth request messages, in the opposite direction.)
>   
The IdP would issue a 302 redirect back to the RP, through the user-agent.
>   
>> Of course, the RP would have to remember what
>> location the user-agent originally requested, in order to give the  
>> right
>> content to the user-agent.
>> 
>
> The content (IdP's response) never reaches the RP in this case; it  
> ends up in the user-agent.
>   
Even if the IdP issues a HTTP 302 redirect, with the Location header set
to the OpenID response endpoint for the RP?
>   
>> As far as I can tell, HTTP redirects are already supported in some
>> current (pre 2.0) OpenID implementations, so I'm still not sure  
>> what the
>> problem is with allowing HTTP redirect implementations in OpenID 2.0.
>> 
>
> HTTP redirects work with pre 2.0 (and 2.0), but only with GET  
> requests and the parameters encoded in the redirect URL.
>
> I don't see how HTTP redirects can work with POSTs, which is why I  
> believe the solution was to use POSTs and HTML FORM redirection in 2.0.
>   
The SAML 2.0 HTTP POST binding may be used with the SAML 2.0 HTTP
Redirect binding ([1]) to offer this functionality. I imagine it's
possible for OpenID to do something similar.

>
> Johnny
>
> ___
> 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: OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP)

[John Kemp]

Dick Hardt wrote:
>>>
>>> Supporting payloads larger then 2K is a requirement.
>>
>> I guess I don't understand what this 2K limit is (and this is not
>> mentioned in the spec) - are you talking about limits on the URL size
>> when doing an HTTP GET?
> 
> yes
> 
>> If so, why not use POST instead?
> 
> Now I am really confused about what you are talking about

I /think/ the limit you are talking about is that regarding the size of
the URL. The reason you might approach or exceed that limit would be if
you were sending an HTTP GET with parameters appended to the URL. The
solution to that issue is to encode the data as an HTTP FORM POST,
which, AFAIK has no such limit. As I understand it, that would be a
separate issue than whether the protocol is transacted via HTTP 3XX
redirects through the user-agent, vs. making the user-agent do the
redirect "manually".

But as I mentioned, I have to admit I'm not totally sure what 2K limit
you're actually talking about.

>>>
>>> How would you suggest the servers determine wether to use GET or POST?
>>
>> Can't YADIS be used to obtain such metadata from the IdP?
> 
> That does not make any sense. You are stating that the user agent might
> not be able to support JS. Not supporting JS would mean the RP / OP
> would need to figure out what the user agent supported so that it could
> decide on using GET or POST.

I'm expecting that the servers can use existing means (determining the
browser type and version through the user-agent string) if they want to
try that.

But what I meant was that the servers (RP and IdP) have to agree on
whether they will use one thing or the other, no? The RP could just try
it out I guess, but it could also look in the IdP's YADIS doc. and find
out whether the authentication service at the IdP supports GET, POST or
both.

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

Re: OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP)

[John Kemp]

Dick Hardt wrote:
> On 16-Nov-06, at 11:41 PM, Matt Pelletier wrote:
>> On Nov 17, 2006, at 1:24 AM, Dick Hardt wrote:
>>
>>> Hi John
>>>
>>> So that a message can be more then 2K of data.
>>>
>>
>> Is it possible to update the language so 1) we don't deprecate HTTP
>> redirects and 2) the form redirect method is described as the
>> preferred/recommended approach, but is not required? You could even
>> stress that HTTP redirects should only be used when the HTTP client's
>> capabilities/limitations would adversely affect the application
>> behavior (or user experience, whatever language is more appropriate
>> for the spec) if form redirects were attempted.
>> I agree with John on the basis that not all HTTP clients will have JS
>> functionality, whether disabled or unavailable, and whether we can
>> imagine what those clients would be or not (blackberry, mobile phone,
>> iPod, Nike running shoe, car keys). The choice to deprecate HTTP
>> redirects involves some assumptions that seem too broad:
>>
>> 1) Payloads will be > 2K often enough that there is little value in
>> supporting more than one way to redirect
> 
> Supporting payloads larger then 2K is a requirement.

I guess I don't understand what this 2K limit is (and this is not
mentioned in the spec) - are you talking about limits on the URL size
when doing an HTTP GET? If so, why not use POST instead?

> I foresee this to
> be fairly common in the future as digitally signed claims get moved around.
> 
>> 2) JS will be available to automate the user experience, or at least
>> that automating the user experience isn't that important.
> 
> JS is widely available now, and if not, the user needs to click a
> button, so things still work. In an AJAX world, this is pretty much a
> given now.

As you note below, JS/AJAX-capable browsers may be present on high-end
phones, but there aren't many of those in comparison to lower-end phones.

> 
>> 3) Deprecating functionality already built into the key spec (HTTP),
>> that is already in use in OpenID 1.x, is preferred to supporting it,
>> even though form redirects will involve more moving parts and specs
>> (ECMA / JS) to maintain the same basic user experience.
> 
> Moving to one way to do things instead of two is desirable. If POST
> turns out to be a real issue in the real world, then we can revisit.
> Libraries are supporting both.
> 
> It also allows a good separation from URL parameters private to the RP
> and request parameters intended for the OP.
> 
>>
>> What do you think?
> 
> How would you suggest the servers determine wether to use GET or POST?

Can't YADIS be used to obtain such metadata from the IdP?

- John

> 
>>
>> Dick, do you have a list of the browsers you tested against?
> 
> We tested on a TREO and high end Nokia and Sony Ericson. The types of
> phones that people could do HTML browsing with. WAP is out of scope.
> 
> 

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

Re: OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP)

[John Kemp]

Hi Dick,

My point is that I don't think requiring JS for a reasonable user
experience is a good idea when considering the variety of browsers that
are deployed today, and I don't understand why it's necessary.

I am interested to know why one would decide to restrict the protocol
this way. Can you perhaps illuminate the reasoning?

Cheers,

- John

Dick Hardt wrote:
> Hi John
> 
> Would you provide examples of those browsers? Testing we did 2 years
> again indicated the JS redirect worked on all the platforms we tested on.
> 
> -- Dick
> 
> On 16-Nov-06, at 11:35 AM, John Kemp wrote:
> 
>> Hi,
>>
>> Sorry I'm just reading this, but I just wanted to put in a point very
>> much in favour of NOT deprecating support for HTTP redirects in OpenID
>> 2.0.
>>
>> I'll note that requiring the user to press a 'submit' button to "push"
>> seems like a dodgy UI strategy. So then you require JavaScript to
>> produce a reasonable user experience.
>>
>> Well, as a representative from the mobile community, I'll tell you that
>> there are quite a few browsers out there (on deployed mobile phones)
>> that still don't support JS in any useful way!
>>
>> So with OpenID 2.0, you may now be requiring many users to click a form
>> submit.
>>
>> Regards,
>>
>> - John
>>
>> Johannes Ernst wrote:
>>> Well, as I've said before, I strongly believe that tying authentication
>>> to one particular HTTP verb is a bad idea, and unnecessary.
>>>
>>> I also believe that involving JavaScript in what is fundamentally an
>>> HTTP-level kind of protocol is a hack. It very likely is either
>>> unnecessary or points to a flaw in the conceptual model of the protocol,
>>> or both.
>>>
>>> The same may be true about having different protocols for thin-client
>>> and rich-client.
>>>
>>> Having said that, I am not making this point more strongly than I have
>>> because I don't think these issues are fatal and I don't want to raise
>>> more issues that delay OpenID 2.0 auth further. So I will log this as a
>>> bug against auth 2.0 as soon as it is published (and as soon as there is
>>> a place where to file bugs against the spec ;-)) but will bite my tongue
>>> in the meantime.
>>>
>>>
>>> On Nov 12, 2006, at 20:29, Dick Hardt wrote:
>>>
>>>>
>>>> On 12-Nov-06, at 8:19 PM, Adam Nelson wrote:
>>>>
>>>>> Hi Dick:
>>>>>
>>>>>> I think REST support is a really useful feature, and have described
>>>>>> how that might happen in the past, but right now we are pretty
>>>>>> focussed on getting browser based auth finalized, and I think the
>>>>>> mechanisms for rich clients will be related, but slightly different.
>>>>>
>>>>> That all makes sense, thanks.  Is that to say that rich client support
>>>>> isn't a goal of v2.0 of the spec, or just a goal subsequent to the
>>>>> conclusion of browser-based auth?
>>>>
>>>> Not a goal of OpenID Authentication 2.0
>>>>
>>>> I think it would make sense to make it a separate document, and would
>>>> value your involvement!
>>>>
>>>> -- Dick
>>>> ___
>>>> specs mailing list
>>>> specs@openid.net
>>>> http://openid.net/mailman/listinfo/specs
>>>
>>>
>>>
>>> Johannes Ernst
>>> NetMesh Inc.
>>>
>>>
>>>
>>> 
>>>
>>>
>>> 
>>>
>>>  http://netmesh.info/jernst
>>>
>>>
>>> 
>>>
>>> ___
>>> 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: OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP)

[John Kemp]

Hi,

Sorry I'm just reading this, but I just wanted to put in a point very
much in favour of NOT deprecating support for HTTP redirects in OpenID 2.0.

I'll note that requiring the user to press a 'submit' button to "push"
seems like a dodgy UI strategy. So then you require JavaScript to
produce a reasonable user experience.

Well, as a representative from the mobile community, I'll tell you that
there are quite a few browsers out there (on deployed mobile phones)
that still don't support JS in any useful way!

So with OpenID 2.0, you may now be requiring many users to click a form
submit.

Regards,

- John

Johannes Ernst wrote:
> Well, as I've said before, I strongly believe that tying authentication
> to one particular HTTP verb is a bad idea, and unnecessary.
> 
> I also believe that involving JavaScript in what is fundamentally an
> HTTP-level kind of protocol is a hack. It very likely is either
> unnecessary or points to a flaw in the conceptual model of the protocol,
> or both.
> 
> The same may be true about having different protocols for thin-client
> and rich-client.
> 
> Having said that, I am not making this point more strongly than I have
> because I don't think these issues are fatal and I don't want to raise
> more issues that delay OpenID 2.0 auth further. So I will log this as a
> bug against auth 2.0 as soon as it is published (and as soon as there is
> a place where to file bugs against the spec ;-)) but will bite my tongue
> in the meantime.
> 
> 
> On Nov 12, 2006, at 20:29, Dick Hardt wrote:
> 
>>
>> On 12-Nov-06, at 8:19 PM, Adam Nelson wrote:
>>
>>> Hi Dick:
>>>
 I think REST support is a really useful feature, and have described
 how that might happen in the past, but right now we are pretty
 focussed on getting browser based auth finalized, and I think the
 mechanisms for rich clients will be related, but slightly different.
>>>
>>> That all makes sense, thanks.  Is that to say that rich client support
>>> isn't a goal of v2.0 of the spec, or just a goal subsequent to the
>>> conclusion of browser-based auth?
>>
>> Not a goal of OpenID Authentication 2.0
>>
>> I think it would make sense to make it a separate document, and would
>> value your involvement!
>>
>> -- Dick
>> ___
>> specs mailing list
>> specs@openid.net
>> http://openid.net/mailman/listinfo/specs
> 
> 
> 
> Johannes Ernst
> NetMesh Inc.
> 
> 
> 
> 
> 
> 
> 
> 
>  http://netmesh.info/jernst
> 
> 
> 
> 
> ___
> 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: Authentication Authority (was RE: IdP vs OP (WAS: RE: "Editors" Conference Call))

[John Kemp]

Hi Drummond,

If what we're trying to express is merely that an OpenID can provide an
authentication assertion, then I agree that "authentication authority"
is quite appropriate.

I would note that in SAML at least (as I understand it - correct me if
I'm wrong Eve!), an authentication authority is not (in that role at
least) being requested to actually authenticate the user (ie. to
actually perform the authentication at that moment) - the request is
only asking whether the authority can make an authentication assertion
(ie. it's a query for authentication assertions, rather than an
authentication request - which may have already been fulfilled).

I don't know if that rather subtle difference is of any interest in OpenID?

- John

Drummond Reed wrote:
> Eve,
> 
> Welcome, and thanks for "delurking" ;-)
> 
> I'm fascinated by your suggestion that the SAML vocabulary includes the term
> "authentication authority". I'd vote for the OpenID Authentication 2.0
> specification (and the community at large) to adopt that term in a heartbeat
> because: 
> 
> a) I've many times thought that "authentication authority" was PRECISELY the
> role that the IdP/OP played in OpenID Authentication.
> 
> b) I'm all for consistency with the SAML glossary because I know it was
> intended to be specification-neutral and I'm a big supporter of harmonizing
> vocabularies in a problem space (that's why we spent so long on the XRI
> glossary in the identifier problem space -- see appendix C of
> http://www.oasis-open.org/committees/download.php/15377). 
> 
> c) It allows us to step around all the semantic issues around whether an
> OpenID IdP is really "providing an identity" or not (and also whether OpenID
> is using classic "identity federation" or not.)
> 
> =Drummond 
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Eve L. Maler
> Sent: Tuesday, November 07, 2006 8:16 AM
> To: specs@openid.net
> Subject: Re: IdP vs OP (WAS: RE: "Editors" Conference Call)
> 
> Delurking for the first time on this list: :-)
> 
> Drummond and I are on the same page about many things, but John is 
> right that SAML is agnostic as to the strength/significance of the 
> service being provided and so the two cases are much more similar 
> than different.  On balance I prefer "identity provider" because 
> it's intuitive in an English sense, it's used in several technology 
> contexts (not just SAML and OpenID), and it avoids a terminological 
> "branding" that would otherwise seem to suggest a conceptual 
> divergence that doesn't -- to my mind -- exist.
> 
> (By the way, there's another term SAML defines that seems to fit the 
> bill of what Drummond is going for here: "authentication authority". 
>   This is not quite synonymous with "identity provider" in 
> SAML-land, but it's close -- much the way that "relying party" and 
> "service provider" are often close to the same thing.  I'm not 
> seriously advocating using it -- just noting that the same software 
> component in an actual deployment can be seen in various lights and 
> have multiple names (roles!).)
> 
> FWIW,
> 
>   Eve
> 
> John Kemp wrote:
>> Hi Drummond,
>>
>> Drummond Reed wrote:
>>> So why, indeed, is there so much interest in OpenID? I believe it's
> because
>>> of the trust model. To the best of my knowledge, it is radically
> different
>>> than the trust model assumed by the majority of use cases which led to
> SAML
>>> and the Liberty Alliance specs. As Eve Maler of Sun puts it, OpenID
> supports
>>> "promiscuous federation" -- RPs and OPs that don't know anything at all
>>> about each other. 
>> At http://www.openidp.org you'll find a promiscuous SAML IdP.
>>
>> While I agree with you that OpenID has been focused on this use-case,
>> with an eye to the use-cases satisfied by SAML, I'd say that SAML has
>> been developed with federated use-cases, but also with an eye to
>> promiscuity.
>>
>> But to put it another way, the trust model used with SAML is
>> out-of-scope for development of the SSO protocol itself.
>>
>> Just like it is for OpenID.
>>
>>> And it doesn't stop there. OpenID also supports OPs that
>>> ***have zero control over the user's OpenID identifier***. The OP simply
>>> provides a service for authenticating that a user has control of the
> OpenID
>>> identifier about which the OP is being queried.
>> An

Re: IdP vs OP (WAS: RE: "Editors" Conference Call)

[John Kemp]

Hi Pete,

We're in agreement - I was just noting that a SAML IdP is asserting the
link between an identifier and a user/subject/principal, which is the
same as OpenID.

As you say, in SAML, the identifier is often (but doesn't have to be)
created by the IdP. And, as you say, in OpenID, the identifier is often
(but doesn't have to be) created by the user.

Regards,

- John

Pete Rowley wrote:
> John Kemp wrote:
>> Drummond Reed wrote:
>>  
>>> And it doesn't stop there. OpenID also supports OPs that
>>> ***have zero control over the user's OpenID identifier***. The OP simply
>>> provides a service for authenticating that a user has control of the
>>> OpenID
>>> identifier about which the OP is being queried.
>>> 
>>
>> And how does one authenticate that the user has control over an
>> identifier? Is it not by having the OpenID IdP having some secret shared
>> with the user - maybe a password, say?
>>
>> A SAML IdP also authenticates that an identifier (issued by the IdP in
>> the SAML case) is bound to a particular user.
>>   
> "issued by the IdP in the SAML case" is really the point. While an
> identifier /may/ be issued by an OpenID provider (IdP, AA, etc.) that is
> really the users choice, the user chooses their identifier and the user
> chooses who is authorized to provide authentication for the identifier.
> So really the OP, IdP, AA etc. isn't providing an identifier or an
> identity. It is providing an identifier ownership assertion service that
> may or may not be backed up by some form of authentication, and that
> service provider may be changed.
> 
> 

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

Re: IdP vs OP (WAS: RE: "Editors" Conference Call)

[John Kemp]

Eve L. Maler wrote:
> On balance I prefer "identity provider" because 
> it's intuitive in an English sense, it's used in several technology 
> contexts (not just SAML and OpenID), and it avoids a terminological 
> "branding" that would otherwise seem to suggest a conceptual 
> divergence that doesn't -- to my mind -- exist.

I agree.

- John

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

Re: IdP vs OP (WAS: RE: "Editors" Conference Call)

[John Kemp]

Dick Hardt wrote:
> 
> On 7-Nov-06, at 7:59 AM, John Kemp wrote:
>>
>> I don't believe that trust is a differentiator between SAML
>> specifications and OpenID Authentication specifications.
>>
>> It is AFAICT, in both cases, simply out of scope.
> 
> I should have been more clear, IdP is a Federation term and implies
> trust between the IdP and the RP.
> That is the definition that many people have about an IdP
> Since trust is NOT required between an OP and an RP in OpenID, a
> different term helps clarify that important point

I'll quit repeating myself after this go around, but:

"It [trust] is AFAICT, in both cases, simply out of scope."

Cheers,

- John


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

Re: IdP vs OP (WAS: RE: "Editors" Conference Call)

[John Kemp]

Dick Hardt wrote:
> 
> On 6-Nov-06, at 11:46 AM, Recordon, David wrote:
> 
>> I see both sides of this discussion.  I think John is correct that the
>> role of an OP really is not that different than that of SAML's IdP.  The
>> difference comes down to the trust model.  I certainly think reputation
>> networks will exist which rate OPs, RPs, users, etc and will ultimately
>> be needed for a technologies with "promiscuous trust models" to thrive
>> in a large scale.
>>
>> I guess reading more of this is making me question if renaming IdP
>> really is the best thing to do in OpenID.  I think if anything we all,
>> as a larger community, should be working to bring OpenID and SAML closer
>> together versus driving them further apart.
> 
> I don't see this as driving SAML apart from OpenID. I see it as
> differentiating OpenID as being user-centric vs federated.
> The IdP has
> specific meaning in the federated world. A key differentiator with
> OpenID is that trust is not needed between the OP and the RP. It is
> implied and perhaps needed in the IdP / RP relationship.

I don't believe that trust is a differentiator between SAML
specifications and OpenID Authentication specifications.

It is AFAICT, in both cases, simply out of scope.

I would hope that whatever ends up being the actual technical definition
of an OpenID Identity Provider (how about OIdP? ;) does not limit that
entity to /only/ doing "untrusted" identity provision.

Regards,

- John



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

Re: IdP vs OP (WAS: RE: "Editors" Conference Call)

[John Kemp]

Hi Drummond,

Drummond Reed wrote:
> So why, indeed, is there so much interest in OpenID? I believe it's because
> of the trust model. To the best of my knowledge, it is radically different
> than the trust model assumed by the majority of use cases which led to SAML
> and the Liberty Alliance specs. As Eve Maler of Sun puts it, OpenID supports
> "promiscuous federation" -- RPs and OPs that don't know anything at all
> about each other. 

At http://www.openidp.org you'll find a promiscuous SAML IdP.

While I agree with you that OpenID has been focused on this use-case,
with an eye to the use-cases satisfied by SAML, I'd say that SAML has
been developed with federated use-cases, but also with an eye to
promiscuity.

But to put it another way, the trust model used with SAML is
out-of-scope for development of the SSO protocol itself.

Just like it is for OpenID.

> And it doesn't stop there. OpenID also supports OPs that
> ***have zero control over the user's OpenID identifier***. The OP simply
> provides a service for authenticating that a user has control of the OpenID
> identifier about which the OP is being queried.

And how does one authenticate that the user has control over an
identifier? Is it not by having the OpenID IdP having some secret shared
with the user - maybe a password, say?

A SAML IdP also authenticates that an identifier (issued by the IdP in
the SAML case) is bound to a particular user.

> 
> This is a big deal. In fact, the closer you get to it, the bigger it is.
> 
> As a result, even though an OP seems to fit the SAML definition of an IdP --
> and many technical folks will be very comfortable treating the two as
> synonymous -- getting the semantics right to stress who really is in control
> of the identity ***right down to the identifier*** is very important.
> 

I don't think we need to worry about fitting the SAML glossary
definition of an IdP, but rather we should focus on making an OpenID
glossary definition that makes sense for what OpenID is doing.

> Whatsmore, I don't think this should or will "drive SAML and OpenID further
> apart". In factit could actually help pave the path to convergence: an OP
> can be defined as being a SAML IdP that provides identifier authentication
> services using the OpenID protocol, which may end out (3.0?) becoming a very
> specific set of SAML capabilities.

As noted earlier, I think a SAML IdP also provides "identifier
authentication". I don't worry so much about convergence of these
technologies (although that would be nice ;), but more about giving a
converged message to users, developers, and purchasers of these
technologies.

Regards,

- John

> 
> =Drummond 
> 
> -Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Recordon, David
> Sent: Monday, November 06, 2006 11:46 AM
> To: Dick Hardt; John Kemp; Patrick Harding
> Cc: specs@openid.net
> Subject: IdP vs OP (WAS: RE: "Editors" Conference Call)
> 
> I see both sides of this discussion.  I think John is correct that the
> role of an OP really is not that different than that of SAML's IdP.  The
> difference comes down to the trust model.  I certainly think reputation
> networks will exist which rate OPs, RPs, users, etc and will ultimately
> be needed for a technologies with "promiscuous trust models" to thrive
> in a large scale.
> 
> I guess reading more of this is making me question if renaming IdP
> really is the best thing to do in OpenID.  I think if anything we all,
> as a larger community, should be working to bring OpenID and SAML closer
> together versus driving them further apart.
> 
> --David
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Dick Hardt
> Sent: Wednesday, November 01, 2006 2:20 PM
> To: John Kemp
> Cc: specs@openid.net
> Subject: Re: "Editors" Conference Call
> 
> 
> On 1-Nov-06, at 12:28 PM, John Kemp wrote:
>> OK. Just checking. So an IdP/OP can choose whether or not to trust a 
>> particular RP, based on some out-of-ban criteria. And an RP can choose
> 
>> whether or not to trust the assertions of a particular IdP/OP? OK 
>> good.
> 
> Technically possible, yes for the RP to decide on an IdP/OP.
> Currently, there is no verified RP identity, so the IdP/OP cannot make
> that decision.
> 
>>> I have not had a chance to wade into that discussion.
>> I'd highly recommend it when you get the chance.
> 
> in my queue :)
> 
>>>> I suspect the latter case will be unlikely, if OpenID is to be 
>>>> successful.
>>> And I do not. And that is the big driver why it should be OP instead 
>>

Re: "Editors" Conference Call

[John Kemp]

Dick Hardt wrote:

>> It would be nice to see a clear definition of an OP in order to
>> determine the exact differences between such an entity and an IdP, but,
>> in the absence of such, some questions:
>>
>> Dick Hardt wrote:
>>> Thanks David! ;-)
>>>
>>> Patrick, as you point out, Identity Provider is a well understood
>>> term in SAML and WS-*. Here is the definition from SAML 2.0 [1]
>>>
>>> Identity Provider: A kind of service provider that creates,
>>> maintains, and manages
>>> identity information for principals and provides principal
>>> authentication to other service providers within a federation, such
>>> as with web browser profiles.
>>>
>>> Per the definition, Identity Provider implies a federation or trust
>>> relationship between the IdP and RP.
>>
>> And I guess there is no similar concept in OpenID? Like perhaps an RP
>> adds a particular (I hate to use the word) "trusted" IdP to a whitelist
>> of IdPs from whom it accepts assertions? Or vice-versa?
> 
> Is it technically possible?

OK. Just checking. So an IdP/OP can choose whether or not to trust a
particular RP, based on some out-of-ban criteria. And an RP can choose
whether or not to trust the assertions of a particular IdP/OP? OK good.

>  Yes. Just like it is technically possible
> for SAML to be user-centric. :-)
> 
>>
>> Admittedly, such "federations" might not be as linked to static business
>> agreements perhaps as in a typical SAML deployment, but it seems they
>> would be necessary unless you base "trust" on public key-based
>> mechanisms, or decide that you'll accept assertions from
>> "no-password.com" (to quote from a discussion on [EMAIL PROTECTED])
>> and anyone else.
> 
> I have not had a chance to wade into that discussion.

I'd highly recommend it when you get the chance.

> 
>> I suspect the latter case will be unlikely, if OpenID
>> is to be successful.
> 
> And I do not. And that is the big driver why it should be OP instead of
> IdP.

I think what you're trying to say is that OpenID won't depend on static
trust relationships (like business contracts) between RPs and IdP/OPs -
is that right? In which case, sure, I get that.

But I do think OpenID will depend on there emerging a way of some RP
trusting (or not) some IdP (and vice-versa). Whitelists and blacklists
seem like a scalable and dynamic way of doing that, and would seem to be
a reasonable way of minimizing the presence of rogue IdPs. Don't take my
word for it though - look at the discussion on [EMAIL PROTECTED]

> 
> 
>>
>>> Additionally, IdPs often provide
>>> other assertions about the user.
>>
>> This is sometimes called "attribute exchange". In OpenID, is it then not
>> possible for an OP to exchange attributes related to a particular OpenID
>> with an RP? There seems to be an "attribute exchange" specification
>> (http://openid.net/specs/openid-attribute-exchange-1_0-02.html) where it
>> says (for example, in section 2) "Fetch retrieves attribute information
>> from an Identity Provider, while store saves or updates attribute
>> information on the Identity Provider.".
> 
> When I talk about assertions, I mean third party claims, not self
> asserted data.
> The OP is not verifying the accuracy of any of the attributes in
> attribute exchange.

A claim by my IdP/OP /might/ be a claim by a third-party, no? And if the
IdP/OP makes such a claim on my behalf (and is not under my direct
control), won't it at least want to verify that the subject of the claim
is also the user whose identifier it asserted in OpenID Authentication?

> 
>>
>>>
>>> In OpenID Authentication, there is no trust relationship requirement
>>> between the IdP and RP., and the only thing the IdP asserts is a
>>> binding between the user and an identifier (OpenID URL or i-name).
>>
>> And on what basis does the OP "assert" this binding to an RP? Doesn't
>> the OP typically "authenticate" that binding, or does it simply take the
>> users identifier on blind faith, and assert away?
> 
> The OP authenticates the user (how the OP authenticates the user is out
> of scope of the spec).

OK - so the user probably maintains an "account" with the OP, very much
like a user would with an IdP? Unless the user runs her own OP.

> 
> 
>>
>>>
>>> As people familiar with SAML / WS-* review the OpenID Authentication
>>> specification, there has been some confusion on exactly what the IdP
>>> does in OpenID. To make it clear that an IdP in OpenID is not the
>>> same as typical deployments in SAML, we decided to call it the OpenID
>>> Provider, which is more precise, and reduces ambiguity.
>>
>> I guess until we see this precise definition, we won't be able to see
>> the precise differences.
> 
> How about:
> 
> An OpenID Provider acts on behalf of the user in responding to
> OpenID Authentication requests from a Relying Party.
> 
> What more do we need in the spec then that?

What about:

"An OpenID Identity Provider acts on behalf of the user in responding to
OpenID Authentication requests from a Relyi

Re: "Editors" Conference Call

[John Kemp]

Hi Dick,

It would be nice to see a clear definition of an OP in order to
determine the exact differences between such an entity and an IdP, but,
in the absence of such, some questions:

Dick Hardt wrote:
> Thanks David! ;-)
> 
> Patrick, as you point out, Identity Provider is a well understood  
> term in SAML and WS-*. Here is the definition from SAML 2.0 [1]
> 
> Identity Provider: A kind of service provider that creates,  
> maintains, and manages
> identity information for principals and provides principal
> authentication to other service providers within a federation, such
> as with web browser profiles.
> 
> Per the definition, Identity Provider implies a federation or trust  
> relationship between the IdP and RP.

And I guess there is no similar concept in OpenID? Like perhaps an RP
adds a particular (I hate to use the word) "trusted" IdP to a whitelist
of IdPs from whom it accepts assertions? Or vice-versa?

Admittedly, such "federations" might not be as linked to static business
agreements perhaps as in a typical SAML deployment, but it seems they
would be necessary unless you base "trust" on public key-based
mechanisms, or decide that you'll accept assertions from
"no-password.com" (to quote from a discussion on [EMAIL PROTECTED])
and anyone else. I suspect the latter case will be unlikely, if OpenID
is to be successful.

> Additionally, IdPs often provide  
> other assertions about the user.

This is sometimes called "attribute exchange". In OpenID, is it then not
possible for an OP to exchange attributes related to a particular OpenID
with an RP? There seems to be an "attribute exchange" specification
(http://openid.net/specs/openid-attribute-exchange-1_0-02.html) where it
says (for example, in section 2) "Fetch retrieves attribute information
from an Identity Provider, while store saves or updates attribute
information on the Identity Provider.".

> 
> In OpenID Authentication, there is no trust relationship requirement  
> between the IdP and RP., and the only thing the IdP asserts is a  
> binding between the user and an identifier (OpenID URL or i-name).

And on what basis does the OP "assert" this binding to an RP? Doesn't
the OP typically "authenticate" that binding, or does it simply take the
users identifier on blind faith, and assert away?

> 
> As people familiar with SAML / WS-* review the OpenID Authentication  
> specification, there has been some confusion on exactly what the IdP  
> does in OpenID. To make it clear that an IdP in OpenID is not the  
> same as typical deployments in SAML, we decided to call it the OpenID  
> Provider, which is more precise, and reduces ambiguity.

I guess until we see this precise definition, we won't be able to see
the precise differences.

>From what I can tell so far, it seems to me that the differences between
an OP and an IdP are not significant.

- John
> 
> -- Dick
> 
> [1] http://www.oasis-open.org/committees/download.php/11886/saml- 
> glossary-2.0-os.pdf
> 
> On 30-Oct-06, at 10:27 PM, Recordon, David wrote:
> 
>> I'll let Dick explain since it was his proposal and I didn't really  
>> care about if we changed the name or not. ;)
>>
>> --David
>>
>> From: Patrick Harding [mailto:[EMAIL PROTECTED]
>> Sent: Monday, October 30, 2006 7:47 PM
>> To: Recordon, David; specs@openid.net
>> Subject: RE: "Editors" Conference Call
>>
>> Dave,
>> Can you please clarify how an OpenID Provider is 'very' different  
>> from the role of Identity Provider as defined in SAML or WS-*.
>> Thanks
>> - Patrick
>>
>>> Rename "Identity Provider" to "OpenID Provider" (IdP -> OP) to add
>> clarity to the term since IdP has a very different meaning in the SAML
>> and WS-* worlds
>>
>>
>>
>>
>> -Original Message-
>> From: [EMAIL PROTECTED] on behalf of Recordon, David
>> Sent: Mon 10/30/2006 7:51 PM
>> To: specs@openid.net
>> Subject: "Editors" Conference Call
>>
>> This morning Dick, Josh, and I got on Skype for 2.5 hours to try and
>> hash through all the remaining proposals.  Unfortunately Brad couldn't
>> join us, though I did talk to him about some of this stuff as well
>> beforehand.
>>
>>  - Authentication Age will be developed as an extension due to  
>> questions
>> around what is the best way for it to work, what features does it  
>> need,
>> etc
>>
>>  - The field "setup_url" will be removed from a checkid_immediate
>> response, rather the RP should fallback to a checkid_setup request to
>> complete the transaction.  It has been found that in the, albeit few,
>> implementations of checkid_immediate this is the behavior for the
>> setup_url anyway.
>>
>>  - Support bare requests by having the field "openid.return_to" as
>> optional in checkid_* requests.  There is a worry of user's not  
>> knowing
>> when they'll be redirected back and when they won't, though that will
>> only be worked out by allowing this functionality.
>>
>>  - Clarify that the openid.realm parameter should be used to uniquely
>> identifier relying parties
>>
>>  - There ar

Re: Making identities persistent?

[John Kemp]

Hello,

I think you need the ability for a user to change his identifier at the
RP (as George notes below) and also at the IdP. In addition, it should
be possible for the IdP to providing OpenID "forwarding" if the user
leaves for another IdP (perhaps the user will even pay for a forwarding
service?)

We're not talking about persistence as such (a particular users OpenID
can surely change over time?), but more the ability for the user to
update her OpenID when she switches from one IdP to another. At the IdP,
this would I guess be kind of like leaving a forwarding address, as the
user is "leaving" one IdP and moving to another. At the RP, the user is
telling the RP that he is using a new IdP.

So, I think George's (1) is a necessity, and agree that (2) is a
business decision, but certainly offers the ability for an IdP to be
"community-friendly" if it so wishes, and may even be a good business
decision.

Isn't this all about the likely /lack/ of persistence in a particular
OpenID though?

Regards,

- John

Hallam-Baker, Phillip wrote:
> If we want identities to be persistent then we are going to need to
> introduce a layer of indirection.
> 
> This normally gets me worried about patents and such. Fortunately
> Multics did this, so did UNIX and VMS. Plenty of prior art.
> 
> If we are serious about decentralization then map the user identifier
> onto a randomly assigned machine readable GUID.
> 
>> -Original Message- From: [EMAIL PROTECTED] 
>> [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Görling Sent:
>> Wednesday, November 01, 2006 10:52 AM To: Shutra Zhou Cc:
>> specs@openid.net Subject: Re: Making identities persistent?
>> 
>> 
>> The reasons for raising this question was partly that I've been
>> doing some research on how people use e-mail addresses and sad to
>> say, you can not expect the user to make wise choices. And even so,
>> companies go broke even the best ones. Services comes and
>> disappear. In my research over half of the population use
>> non-portable e-mail addresses tied to an employer, university, etc.
>> and is likely to only live a few years.
>> 
>> E-mail is not a stable address/identity identifier. We must not
>> rely on it as such.
>> 
>> If we want an identity to be persistent, it must contain a 
>> migration feature, so that I can move all their trust relations
>> from one place to another. This of course creates a number of other
>> issues such as security and complexibility, but it is my sincere
>> belief that the issue should be addressed by the system and not
>> only delegated to be dependent on wise user decisions.
>> 
>> Therefore, my +1 is on (1) below. I will try to read back on what
>> has been said in the past on a 'change identifier' extension and
>> see if there is anything I can do to help.
>> 
>> /Stefan
>> 
>>> Yes, this is important thing I thought. We should privide a
>> spec for
>>> the consumer to change their end user's OpenID URL,
>> optionally the end
>>> user can use multiple OpenIDs in this consuemr. And this
>> case can be
>>> expended as this, the IdP（OpenID Server） is closed down.
>>> 
>>> 2006/10/31, George Fletcher <[EMAIL PROTECTED]
>> >:
>>> This is a good use case and I think important for both users and 
>>> IdPs (now OPs [OpenID Provider] per the latest "editor's 
>>> conference") to consider.
>>> 
>>> I see a number of options...
>>> 
>>> 1. There has been some discussion regarding a "change
>> identifier"
>>> extension that would allow you to change your identifier at the 
>>> relying party.  This would solve the use case and is necessary 
>>> regardless of the other options.
>>> 
>>> 2. The OP (in this case AOL.com) could continue to provide an 
>>> "identifier management" page that would allow the user
>> to specify
>>> the OP of choice.  This requires the OP to continue to serve the 
>>> XRDS doc or at least the indirection to a XRDS doc with the new 
>>> OP.  This is not that much extra overhead for the OP,
>> but it will
>>> likely be a business decision as to whether to support
>> such a feature.
>>> 3. The user gets to choose their OP so they can ensure that they 
>>> don't get "locked in".  This is the ideal behind user-centric. 
>>> However, in practice, it will take good education and time for 
>>> users to understand the ramifications of their decisions.
>>> 
>>> Thanks, George
>>> 
>>> Stefan Görling wrote:
>>> 
 Hi everybody,
 
 I'm trying to get a grip around your great work and have one
 issue that I'm not quite clear on, relevant to the discussion
 of using
 
 [EMAIL PROTECTED] 
>> identifiers, but also in a more general context.
 Please let me know if I've simply missunderstood my own
 question.
 
 
 http://openid.net/specs/openid-authentication-2_0-09.html#an
> chor48 says:
 "OpenID is decentralized. No central authority must approve or
  register Relying Parties or Identity Providers. An End User
>> can freely