Re: Request for comments: Sorting fields in signature generation

[Johnny Bufu]

On 26-Sep-06, at 4:48 PM, Josh Hoyt wrote:
> No one has written a proposal for pass-through arguments and it's not
> in any specification, so it's hard to answer your objection. If
> someone were to propose adding pass-through parameters to the
> specification, I would argue that:

Section 5.2 of draft 9 seems to imply, at least, that pass-through  
parameters are allowed, and specifies how the parties involved in the  
transaction should handle the openid / non-openid parameters.

> a) Including the pass-through arguments in the OpenID signature is not
> necessary (or constructive!)

That may be up to the RP to decide; if it decides that it needs to  
trust such parameters included in an indirect message, by not  
allowing it to use the already existing openid mechanism would only  
add complexity that can be avoided.

> b) It is quite reasonable to restrict them to only one value per  
> parameter name.

It would also be reasonable to place the restriction only on core  
openid parameters, and leave the possibility for them for extensions  
and pass-through parameters.

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

Re: Request for comments: Sorting fields in signature generation

[Johnny Bufu]

On 27-Sep-06, at 10:39 AM, Josh Hoyt wrote:
> On 9/27/06, Johnny Bufu <[EMAIL PROTECTED]> wrote:
>> Section 5.2 of draft 9 seems to imply, at least, that pass-through
>> parameters are allowed, and specifies how the parties involved in the
>> transaction should handle the openid / non-openid parameters.
>
> Huh? I don't see anything in that section about a requirement to echo
> back parameters.

Not a requirement, but I read the second paragraph as implying they  
can/could be used.

If that weren't so, then why is there the "openid." prefix to the  
parameters in some of the messages?


Johnny


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

HTTP response code

[Johnny Bufu]

I was reviewing draft 10 to make sure our implementation complies  
with all MUSTs, and I believe I've spotted an issue with the wording  
in sections 5.1.2.1 and 5.1.2.2, specifically:

"5.1.2.1.  Successful Responses

A server receiving a properly formed request MUST send a response  
with an HTTP status code of 200.

5.1.2.2.  Error Responses

If a request is malformed or contains invalid arguments, the server  
MUST send a response with a status code of 400."

Given that any message is either properly formed or malformed (and  
nothing beside), the two MUSTs above cannot be satisfied in the case  
of a properly formed message, but containing invalid arguments.

Draft 9 had the wording as "valid request" vs "malformed or  
containing invalid arguments" (sections 6.1.2.1 and 6.1.2.2).


Thanks,
Johnny
___
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)

[Johnny Bufu]

On 17-Nov-06, at 11:13 AM, John Kemp wrote:
> 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".

There are a few issues with issuing redirects to POST requests:

- According to the HTTP RFC, user agents receiving a 3XX redirect in  
response to a POST request MUST NOT automatically redirect the request.

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

Note that the OpenID message is different than the initial POST, so a  
re-POST at the new URL wouldn't work either, even if that could be  
automated.


Johnny


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

[Johnny Bufu]

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

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

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

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


Johnny

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

[Johnny Bufu]

On 18-Nov-06, at 6:26 AM, John Kemp wrote:
> 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.

POSTs are required so that there are no size limitation for the  
parameters.

HTML forms is the method chosen to pass the data; the SAML HTTP POST  
binding also seems to be using forms.

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

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

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

The redirect URL would be the RP endpoint, but again I say that the  
response payload never reaches the RP; it ends up in the user-agent.

Maybe you can provide an example (headers + body) of such a HTTP  
redirect, which given in response to a POST will have the user-agent  
POST the payload (the OpenID message) to the redirect URL (RP) ?

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

Yes.

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

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?

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

Re: Terminology update (was RE: OP Identifier vs. OP-Specific Identifier)

[Johnny Bufu]

Drummond,

On 20-Nov-06, at 4:32 PM, Drummond Reed wrote:
> That leaves only 12 OpenID-specific terms on
> http://openid.net/wiki/index.php/Terminology, and only 4 open  
> issues. More
> on those in other threads.

I have added another one to the list - the "User-supplied  
Identifier", referenced in draft 10 "Normalization" and "XRI and the  
CanonicalID Element" sections.


Johnny

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

Re: Comments on Auth 2.0 - Pre-Draft 11

[Johnny Bufu]

Johannes,

On 8-Dec-06, at 11:08 AM, Johannes Ernst wrote:
> Dear Authentication 2.0 editors,
>
> I know you are going to hate me ("more changes!"), but I hope the  
> attached comments are useful as you construct the final version of  
> the OpenID 2.0 Authentication document.

Not at all! As an implementer of the spec, I can assure you that more  
clarity is always desired.

Thanks for all the patches. I've already checked-in some of them, and  
on others I have commented below.


Johnny


> Section 2 - Terminology:
>
> It says:
>> OP Endpoint URL:
>> The URL which accepts OpenID Authentication requests,  
>> discovered by dereferencing the end user's Identifier. This value  
>> MUST be an absolute URL.
>
> "Deferencing" is a term that's unclear in this context.
>
> Better:
>> OP Endpoint URL:
>> The URL which accepts OpenID Authentication requests, found by  
>> performing discovery on the the end user's Identifier. This value  
>> MUST be an absolute URL.
>

Done.

> --
>
> The terminology section (between "User-supplied Identifier" and  
> "Public Identifier") implies that I MUST NOT ever enter a Private  
> Identifier at a Relying Party. While I understand that this might  
> not be the usual case, I don't think it should be prohibited at all.
>
> Better:
>> User-supplied Identifier
>> An Identifier that was presented by the end user to the  
>> Relying Party. During the initiation phase of the protocol, an end  
>> user may enter either a Public Identifier, a Private Identifier or  
>> an OP Identifier. If an OP Identifier is used, the OP may then  
>> assist the end user in selecting either a Public Identifier or a  
>> Private Identifier to share with the Relying Party.
>

The Public-Identifier was removed from the terminology section, as it  
was used in a single other place in the spec. The user-supplied  
identifier can be an identifier that the user owns (private or  
public), or an OP Identifier.

> --
>
> Section 4.1.1 - Key-Value Form Encoding
>
> If in the key-value form, I wish to transmit a value that includes  
> a '\n', what am I supposed to do?

Encode it such that it doesn't have a '\n' in it, e.g using base64.  
If  '\n' was allowed, the protocol would permit the kind of attack  
described in this thread:
http://openid.net/pipermail/specs/2006-November/000901.html

> --
>
> Section 4.1.2 HTTP Encoding
>
> Second paragraph currently says:
>> All of the keys in the request message MUST be prefixed with  
>> "openid.". This prefix prevents interference with other parameters  
>> that are passed along with the OpenID Authentication message. When  
>> a message is sent as a POST, the application processing the HTTP  
>> request MUST only use the values in the POST body and MUST ignore  
>> any GET parameters.
>
> I think I pointed out earlier that this is more restrictive than  
> necessary, and prevents certain implementations that make sense,  
> such as using a service endpoint URL like
> http://example.com/endpoint?bizmodel=free
> http://example.com/endpoint?bizmodel=premium
> because it says that those parameters must be dropped.
>
> Further, are you guys sure that there is such a thing as a "GET  
> Parameter" in the appropriate URI / HTTP standards? If so, I wonder  
> where that is defined, because I can't find it.
>
> Better:
>>  All of the keys in the request message MUST be prefixed with  
>> "openid.". This prefix prevents interference with other parameters  
>> that are passed along with the OpenID Authentication message. When  
>> a message is sent as a POST, the application processing the HTTP  
>> request MUST ignore those values provided as GET parameters for  
>> which identically-named POST parameters exist in the same request.
>
> --
>
> 4.2 Integer representation
>
> I love your use of "henceforth". It has always been one of my  
> favorite words in the English language. ;-)
>
> --
>
> 5.1.2.2 Error Responses, and also
> 5.2.3 Indirect Error Responses
>
> Please clarify which language is supposed to be used for the  
> "error" field, and what a party should do that receives such an  
> error string, such as:
>
>> #  error
>> Value: Unstructured text error message that SHOULD use the  
>> English language. This error message is intended to be used by  
>> technically-savvy personnel to debug problems. It is not intended  
>> to be shown to the end user.
>

My opinion is that specifying a language is out of scope for the  
spec; it's up to the RP/OP to choose it. Being unstructured text, I  
assume it's intended to be passed (eventually) to a human behind the  
party receiving it.

> --
>
> 5.2.2 HTML FORM Redirection
>
> I don't think you need to restrict this to JavaScript. There are  
> other languages, too, and there is no need to create a dependency  
> on JavaScript here. Better:
>>  A mapping of keys to values can be transferred by returning an  
>> HTML page to the User-Agent that contains an HTML form element.  
>> Form submission MAY b

Re: Comments on Auth 2.0 - Pre-Draft 11

[Johnny Bufu]

Hi Johannes,

Josh and I went through the remaining issues, so I have addressed and/ 
or commented on some of them below.

For easier tracking I've inserted [josh] after the ones that Josh  
agreed to handle.


Thanks again for the feedback! The spec looks definitely better now  
than a few days ago.


Johnny


On 11-Dec-06, at 9:41 AM, Johannes Ernst wrote:

> Commenting just on the remaining items ...
>
>>> The terminology section (between "User-supplied Identifier" and  
>>> "Public Identifier") implies that I MUST NOT ever enter a Private  
>>> Identifier at a Relying Party. While I understand that this might  
>>> not be the usual case, I don't think it should be prohibited at all.
>>>
>>> Better:
 User-supplied Identifier
 An Identifier that was presented by the end user to the  
 Relying Party. During the initiation phase of the protocol, an  
 end user may enter either a Public Identifier, a Private  
 Identifier or an OP Identifier. If an OP Identifier is used, the  
 OP may then assist the end user in selecting either a Public  
 Identifier or a Private Identifier to share with the Relying Party.
>>>
>>
>> The Public-Identifier was removed from the terminology section, as  
>> it was used in a single other place in the spec. The user-supplied  
>> identifier can be an identifier that the user owns (private or  
>> public), or an OP Identifier.
>
> I don't understand what you are saying. Are you saying you are  
> making a change to the document (if so, which?) or not, in which  
> case -- are you saying that entering a private identifier at a site  
> is or isn't prohibited? (I am arguing that it should not be  
> prohibited)

During IIW we removed the "Public Identifier" from the definitions  
section, because it was used in only one other place in the document.  
The latest version in SVN allows any type of identifiers (private /  
public / OP-) to be entered at the RP.


>>> Section 4.1.1 - Key-Value Form Encoding
>>>
>>> If in the key-value form, I wish to transmit a value that  
>>> includes a '\n', what am I supposed to do?
>>
>> Encode it such that it doesn't have a '\n' in it, e.g using  
>> base64. If  '\n' was allowed, the protocol would permit the kind  
>> of attack described in this thread:
>> http://openid.net/pipermail/specs/2006-November/000901.html
>
> I understand that is one possible fix. What about we define one of  
> the possible fixes as the "canonical" fix for text data, otherwise  
> different implementors will implement different fixes (base64, C- 
> style \n, URL-style %0D%0a, ... ) and interop will suffer.

[josh]


>>> Section 4.1.2 HTTP Encoding
>>>
>>> Second paragraph currently says:
 All of the keys in the request message MUST be prefixed with  
 "openid.". This prefix prevents interference with other  
 parameters that are passed along with the OpenID Authentication  
 message. When a message is sent as a POST, the application  
 processing the HTTP request MUST only use the values in the POST  
 body and MUST ignore any GET parameters.
>>>
>>> I think I pointed out earlier that this is more restrictive than  
>>> necessary, and prevents certain implementations that make sense,  
>>> such as using a service endpoint URL like
>>> http://example.com/endpoint?bizmodel=free
>>> http://example.com/endpoint?bizmodel=premium
>>> because it says that those parameters must be dropped.
>>>
>>> Further, are you guys sure that there is such a thing as a "GET  
>>> Parameter" in the appropriate URI / HTTP standards? If so, I  
>>> wonder where that is defined, because I can't find it.
>>>
>>> Better:
  All of the keys in the request message MUST be prefixed with  
 "openid.". This prefix prevents interference with other  
 parameters that are passed along with the OpenID Authentication  
 message. When a message is sent as a POST, the application  
 processing the HTTP request MUST ignore those values provided as  
 GET parameters for which identically-named POST parameters exist  
 in the same request.
>
> Is there a proposed solution to this issue or does it remain open?

We've made is a bit more strict; it now reads:

> When a message is sent as a POST, OpenID parameters MUST only be  
> sent in and processed from the POST body.


>>> 5.1.2.2 Error Responses, and also
>>> 5.2.3 Indirect Error Responses
>>>
>>> Please clarify which language is supposed to be used for the  
>>> "error" field, and what a party should do that receives such an  
>>> error string, such as:
>>>
 #  error
 Value: Unstructured text error message that SHOULD use the  
 English language. This error message is intended to be used by  
 technically-savvy personnel to debug problems. It is not  
 intended to be shown to the end user.
>>>
>>
>> My opinion is that specifying a language is out of scope for the  
>> spec; it's up to the RP/OP to choose it. Being unstructured text,  
>> I assum

Re: Comments on Auth 2.0 - Pre-Draft 11

[Johnny Bufu]

On 12-Dec-06, at 11:31 AM, Joaquin Miller wrote:
>> When a message is sent as a POST, OpenID parameters MUST only be  
>> sent in and processed from the POST body.
>
> Does that mean the same as this:
>
>When a message is sent as a POST, OpenID parameters MUST be sent  
> only in the POST body; the parameters processed MUST be only those  
> from the POST body.

The second part of your text should say "OpenID parameters" to be  
equivalent. Also, one could argue that it's not clear if the first  
part ("when a message is sent as a POST") also applies to the second  
statement, the one after the ";".

> If so, is the latter better?

Given the above, I favor the text I came up with yesterday.


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

Re: Consistency of negative responses to checkid_immediate requests

[Johnny Bufu]

On 14-Dec-06, at 12:13 AM, Josh Hoyt wrote:

> On 12/13/06, Martin Atkins <[EMAIL PROTECTED]> wrote:
>> Josh Hoyt wrote:
>>>
>>> It's confusing to me make the failure response to an immediate mode
>>> request be "id_res", especially if that is not the failure response
>>> for setup mode. I can't see a reason that they can't both use the
>>> "cancel" response to indicate that the OP or end user do not wish to
>>> complete the transaction.
>>>
>>> This is a very minor change, but it will make the spec simpler.
>>>
>>
>> I think the RP will want to do something different in these two  
>> cases.
>
> That's true, but the RP will probably need to handle the success case
> differently for immediate mode anyway (e.g. it will have to do AJAX to
> update the page) so I expect it to have a specific return_to URL for
> immediate requests. Since using a different return_to is trivial, I
> prefer the consistency of negative responses.

The current / v1 modes will need to be mentioned in the compatibility  
section, and also implemented. Not sure if this simplification will  
then still be worth.

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

Re: Comments on Auth 2.0 - Pre-Draft 11

[Johnny Bufu]

On 12-Dec-06, at 9:10 AM, Johannes Ernst wrote:

> 11.2.2.2 Response Parameters
>
> Not clear which values MUST be present and which not.
>
> Also:
>
> the language in this section is confusing. I don't quite
> understand it. Not sure I can make a suggestion how to explain
> it better, because so far I don' tunderstand it.
>>
>> I'll try to rephrase the three paragraphs in there. In the
>> meantime, it would help if you could point what you found the most
>> confusing.
>
> I'm just raising the "General Confusion Fault" ;-) That might just be
> me, however.

This is what I've come with for the "Verifying Directly with the  
OpenID Provider" section; does it (start to) make sense?

http://openid.net/svn/listing.php?repname=specifications&path=% 
2F&rev=236&sc=1


Johnny

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

Re: HTML-Based Discovery with OP Identifiers

[Johnny Bufu]

On 28-Dec-06, at 3:47 PM, David Recordon wrote:

> Sitting here in Seattle with Drummond and looking through the  
> spec.  Section
> 7.3.3 says:
>   HTML-based discovery MUST be supported by Relying Parties.  HTML-
>   based discovery is only usable for discovery of Claimed Identifiers.
>   OP Identifiers must be XRIs or URLs that support XRDS discovery.
>
> That is a bit confusing to parse so we were looking at re-wording  
> it.  Issue
> is "Claimed Identifier" is defined as possibly being a "User-Supplied
> Identifier" which in turn can be an "OP Identifier" thus making this
> paragraph fall apart.

To clarify it, how about we remove the Claimed Identifier term from  
the paragraph above, and only specify that HTML discovery cannot use  
OP Identifiers.

> This then brought up the question of why can't
> HTML-Based Discovery be used for OP Identifiers?

Because the verification of the discovered information would be  
incomplete.

In the case of an URL Identifier, the claimed id is the final URL.

Now, if the discovered information obtained from that final URL only  
contains a pointer to the OP, basically anyone with an account at  
that OP would be able to claim s/he owns the URL -- when verifying  
the discovered information, there's would be no delegate / local-id  
to be checked and matched.

If we want to allow OP identifiers to be used with HTML discovery, we  
need to re-examine what the claimed id is when using URLs, which  
would be a major change in the spec. So, unless there's an easy  
solution which I'm overlooking, I'd say lets keep it as it is.


Johnny

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

Re: Consistency of negative responses to checkid_immediate requests

[Johnny Bufu]

On 27-Dec-06, at 11:11 AM, Recordon, David wrote:

> I think using "cancel" would add consistency between the modes, any
> reason I'm not seeing why it is a bad choice?

Because then, only from the message contents, the RP wouldn't be able  
to distinguish between responses to immediate and non-immediate  
requests.

Josh argued that in most cases the RPs would use different return_to  
URLs for immediate / non-immediate requests.

My preference would be for option 2, i.e. a new mode. There's a  
different path the RPs have to take in this case, so I think  
openid.mode is the best qualified to express it.


Johnny



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

Re: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman anOpenID?

[Johnny Bufu]

On 3-Jan-07, at 8:55 PM, Recordon, David wrote:
> This thus means you'd no longer be making a claim about
> http://xri.net/=bobwyman, but rather that you own
> http://2idi.com/contact/=bobwyman.  Thus if you change iBrokers, this
> assertion would no longer remain valid.  It also removes the  
> protection
> the iNumber (and CanonicalID tag) adds to the XRI Resolution process
> since i-names can be reassigned.

I believe the short answer here is that xri://=bobwyman and http:// 
xri.net/=bobwyman are two different identifiers (the former an XRI,  
the latter an URL) as far as OpenID is concerned, even though XRI's  
internals uses the URL as part of the XRI discovery.

The XRI is configured for OpenID, but Yadis/HTML discovery fail on  
the URL.

Not sure if/how one could make XRI and URL identifiers synonymous, or  
if something like this would really be desired.

Johnny



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

OpenID Attribute Exchange 1.0 draft 4

[Johnny Bufu]

Hello list!

Please have a look at the latest (draft 4) OpenID Attribute Exchange  
1.0 specification:

http://openid.net/specs/openid-attribute-exchange-1_0-04.html


Summary:

OpenID Attribute Exchange is an OpenID service extension for  
exchanging identity information between endpoints. Messages for  
retrieval and storage of identity information are provided.


The main change since draft 3 is the specification for exchanging  
attributes with multiple values, by having a "count" parameter and  
incremental parameter names for each value.

Other minor changes to clarify some aspects include:
- Added note about the state of flux of the attribute types and  
metadata specifications
- Added definition for 'attribute'
- Explicitly referenced OpenID's extension mechanism as the transport  
for attribute exchanges
- Renamed openid.ax.fetch. to openid.ax.type.
- Added reference to OpenID Authentication's security considerations


We look forward to any feedback and comments from the community  
towards improving the attribute exchange!


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

Re: OpenID Auth 2.0 security considerations

[Johnny Bufu]

David,

No issues from me - I too believe a non-normative link to a wiki site  
would work best, while keeping the security consideration section we  
have now.

Thanks,
Johnny

On 30-Jan-07, at 12:02 PM, Recordon, David wrote:

> Is there a wiki page that exists to point to? Josh and Johnny, see any
> issues with this?
>
> Also any wording to propose Johannes?
>
> Thanks,
> --David
>
> -Original Message-
> From: Johannes Ernst [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 23, 2007 12:57 PM
> To: Recordon, David
> Cc: specs@openid.net
> Subject: Re: OpenID Auth 2.0 security considerations
>
> Given where we are in time, I would suggest to make the smallest  
> amount
> of changes possible to the document, i.e. leave everything as is, just
> add this one link.
>
>
> On Jan 23, 2007, at 11:59, Recordon, David wrote:
>
>> I don't see a problem with that.
>>
>> Would you propose the majority of the security considerations section
>> in the current draft be moved to the wiki?  What would be the balance
>> between spec and wiki page?
>>
>> --David
>>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>> Behalf Of Johannes Ernst
>> Sent: Monday, January 22, 2007 12:15 PM
>> To: specs@openid.net
>> Subject: OpenID Auth 2.0 security considerations
>>
>> What about a non-normative link from the spec to a place on the wiki
>> where we can collect security considerations for it, and update those
>> in real-time as discussions such as the phishing one progress.
>>
>>
>>
>> ___
>> 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 Attribute Exchange 1.0 draft 4

[Johnny Bufu]

Hi Rowan,

On 31-Jan-07, at 1:26 PM, Rowan Kerr wrote:
> On 1/9/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
>> Please have a look at the latest (draft 4) OpenID Attribute Exchange
>> 1.0 specification:
>>
>> http://openid.net/specs/openid-attribute-exchange-1_0-04.html
>
> This is looking good. I've been going over it updating my drupal
> modules to draft 4.

Thanks for the feedback and for supporting AX!

> The multiple values request is nice, and I'm sure we'll find a use for
> it at Standard shortly as we get  a couple of our partners online with
> OpenID and AX. Of course, it's going to be a bit more difficult to get
> PHP behaving with the openid.type..1 but the limitations of one
> language shouldn't hold up the entire spec.

Ideally, this would be handled transparently by the libraries. Not  
sure what the php issues are, but  the JanRain guys said they would  
support AX in their libraries, so you could use theirs, or at least  
see how they handle this.

> One thing that seems to be missing at the moment is how to treat a
> collection of values.
> eg:  You fetch someone's name but want first, last, etc all together
> as one response.
>
> Maybe a ax.type.foo.join value would be useful?
> So then the discrete values of first and last name would be  
> returned by the OP
> joined with whatever was specified in ax.type.foo.join.

What use case are you trying to address? I'm trying to understand why  
you would prefer the join to be performed by the OP, rather than have  
the RP request the pieces it wants, and mix them together as it needs.


>> - Renamed openid.ax.fetch. to openid.ax.type.
>
> So now the only difference between a Fetch and Store is
> the existance of openid.ax.if_available and openid.ax.required
> and openid.ax.value...  I'm not sure if that makes the messages
> harder to deal with because it's more opaque, or if it's nicer
> because the messages are now more standard.

Yes, consistency among all types of messages was the reason for this  
change. But you're right, now they are quite similar. We've realized  
this is less convenient in some cases while implementing AX, and for  
the next draft we plan to add an ax.mode = fetch_request |  
fetch_response | store_request | store_response parameter to address  
this.


Thanks,
Johnny

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

Re: Proposal: An anti-phishing compromise

[Johnny Bufu]

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

Johnny



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

Re: Proposal: An anti-phishing compromise

[Johnny Bufu]

On 2-Feb-07, at 11:10 AM, George Fletcher wrote:
> That depends completely on what the authentication mechanism and  
> even one time use tokens can be phish'd and used to compromise  
> accounts.  For example, the rogue site gets the SecurId and then  
> immediately logs in on its own using the supplied credentials.   
> Those credentials establish a session that can then be used to  
> compromise the account.  So it helps, because the rogue site can't  
> go back and authenticate again after the session is over, but it  
> could easily do plenty of damage (or set up back doors) with just  
> one phish'd session.

Then I would say that the OP was wrong in stating that the  
authentication was unphishale. The meaning of the phishable flag is  
supposed to be "OP's assessment of its authentication mechanisms". If  
it lies or makes a wrong assessment, it's not a very good OP.

> What authentication mechanisms are not phish'able and yet don't  
> require client side code? How many are viable to a user to  
> participate in?  I have a SecurId and it can be a pain even though  
> it protects my account.  Do users want to deal with this level of  
> inconvenience? (The should, but will they?)

Yes, if the security is important to the users, they should deal with  
the slight inconvenience. I say slight because this is exactly where  
OpenID helps -- the user can securely (unphishably) login to their OP  
once, and then not have to do the same for all their 10 bank RPs.

I can't say how many will actually go for this, but I would hope more  
and more will see the security benefits and be willing to pay the  
slight inconvenience price. At any rate, it's their choice, and we're  
trying to make it clear they have it.

Johnny

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

Re: Proposal: An anti-phishing compromise

[Johnny Bufu]

On 2-Feb-07, at 11:22 AM, john kemp wrote:

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

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.

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

The RP only trusts that the user has chosen an OP to suit their  
needs, and OpenID lets the RP make sure the assertions are coming  
from the legitimate / authoritative OP the user has chosen.

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

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


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

Re: Proposal: An anti-phishing compromise

[Johnny Bufu]

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.

>> 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").

Johnny

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

Re: Proposal: An anti-phishing compromise

[Johnny Bufu]

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

Johnny


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

Re: Proposal: An anti-phishing compromise

[Johnny Bufu]

On 2-Feb-07, at 1:53 PM, Josh Hoyt wrote:
> Therefore, I think that the authentication mechanism is (or
> at least can be) independent from whether the authentication channel
> is phishable.

.. or, pushing it a bit further, I could ask/configure my OP to  
always issue "phishable=no" for me, because I am a power user, always  
watch the address bar, check certificates, make sure my machine is  
not compromised, etc. That's also fine, as long as the OP represents  
the user's interests.

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

attribute exchange draft 4 review

[Johnny Bufu]

Hello list!

While reviewing our AX implementation, I came across a case where the  
spec is not clear enough:

openid.ax.required
The value of this parameter is an attribute alias, or a list
of aliases corresponding to the URIs defined by
"openid.ax.type." parameters. The OpenID Provider
MUST provide the identity information specified in this
parameter or return an error condition.

The error condition that the OP is supposed to return is not fully  
specified. We mention in the overview section that standard OpenID  
error messages should be used, but those would indicate a core /  
authentication failure.

My question is how would you, as an implementer on the RP side,  
prefer to be notified that the user / OP were not willing / able to  
supply a required attribute?


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

Re: OpenId & Yadis Question

[Johnny Bufu]

On 25-Feb-07, at 3:35 PM, David Fuelling wrote:

> 1.) User navigates to an RP, and enters a Claimed Identifier (e.g.,
> http://sappenin.gmail.com).
>
> 2.) A Yadis doc is returned as follows:
>
> 
> http://specs.openid.net/auth/2.0/server
> https://sappenin.com/ 
> 
>
> A.) Is this the proper way to do delegation?  Above, gmail.com is  
> delegating
> to sappenin.com.

No; in this way you just declare that the OpenID server for http:// 
sapenin.gmail.com is http://sapenin.com/. Also, if the RP uses this  
service element, it will send an "identifier_select" OpenID auth  
request.

> B.) If a client gets the Yadis doc above (after navigating to  
> gmail.com),
> MUST they (or SHOULD they) navigate to sappenin.com and try to perform
> discovery again?  If so, how many delegates are allowed?  Not  
> specified?

Only one level of delegation. Performing discovery on an URI in a  
service element is not part of the yadis spec.

Johnny

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

Re: Thoughts on the Attribute Exchange proposal.

[Johnny Bufu]

Hi Wayne!

It's good to see someone interested in attribute exchange!

On 9-Mar-07, at 11:25 AM, Wayne Pierce wrote:
>   1. Updating information.  When I update an attribute is there any
> proposed way to notify subscribers without the subscribers having to
> poll my URI?

This is actually addressed in Atribute Exchange, see the update_url  
field in the fetch request messages.

>   2. Is there any way for an entity to create a collection of
> attributes for individuals to associate values with?  I saw a
> reference to "Personas" in one of the documents but these seemed to be
> user-derived.

I'm not sure I understand fully what your interest is with this use- 
case.

In AX, each attribute is identified by a URI, and anyone can come  
up / invent custom attributes like this. [1]

The next step is dereferencing that URI (if it is an URL) and obtain  
'metadata' [2] about the attribute, which would then help do other  
useful things with the attribute. The metadata would describe the  
data format of the attribute, acquisition methods etc.

Using these two mechanisms, it would be easy for someone to define a  
new (profile) attribute like the one you describe below, and define  
it's semantic to be a collection of some other attributes. How does  
this approach look to you? Does it address your problem, or did you  
have a different approach in mind?


While there is some consensus around Attribute Exchange, with its use  
of URI attribute identifiers (and it is slowly heading to a  
finalized / useable form), the other two pieces (types [1] and  
metadata [2]) are not as close to being  finalized, and we'd more  
than welcome your help here!

The talks about the identity schema are focused at http:// 
idschemas.idcommons.net/ which may also be of interest to you.


Thanks,
Johnny

[1] http://openid.net/specs/openid-attribute-types-1_0-02.html
[2] http://openid.net/specs/identity-attribute-metadata-1_0-01.html

> The system I have been looking at is very similar, but seems to start
> from a different perspective.  My starting point was about making an
> organization more efficient and easing the burden of updating my
> information with multiple organizations at once.
>
> To accomplish this I was looking at ways to allow an organization to
> create "Profiles" of Attributes.  In the talks I have had with people
> they seemed to want profiles that match their existing HR documents or
> data they would like to collect but have no documents or processes
> for.
>
> Individuals would then associate Attributes with the fields for a
> Profile, when the local Attribute was updated any Profile containing
> that Attribute would be updated.  This would trigger an update to the
> authorized organizations.
>
> Other things I have looked at are ways to secure the data, potentially
> using GnuPG and building a client application for managing the
> Attributes and Profiles.
>
> I am still reading some of the specs and mailing list archive, but I
> will help out where I can.

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

Re: Is this a bug in the documentation?

[Johnny Bufu]

John,

> Section "4.4.1. Request Parameters" (for the "check_authentication"
> mode) says that I should state a 'mode' in the parameters (and which
> should equal 'check_authenticate'), but it also says:
[...]

In direct verification messages you should be sending  
openid.mode=openid.check_authentication.

What spec are you looking at? The latest version (draft 11) is here:
http://openid.net/specs/openid-authentication-2_0-11.html

.. and it says in Section 11.4.2.1 Request Parameters (under 11.4.2.   
Verifying Directly with the OpenID Provider):

> - openid.mode
>   Value: "check_authentication"
> - Exact copies of all fields from the authentication response,  
> except for "openid.mode".


Hope this answers your question.
Johnny

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

modulus and generator optional in association requests

[Johnny Bufu]

Hello list!

The association request [1] seems to be insufficiently specified:  
openid.dh_modulus and openid.dh_gen are not specifically marked as  
optional, so according to the "Protocol Messages" [2] section they  
should be mandatory.

However, while testing the openid4java code [3], it turns out that  
RPs are not always sending these fields, which makes me believe the  
intent of the default values was to make these fields optional in  
association requests.

So I suggest we mark the two fields as OPTIONAL to both clarify the  
usage and be consistent with section 4.1.


Thanks,
Johnny


[1] http://openid.net/specs/openid-authentication-2_0-11.html#anchor19
[2] http://openid.net/specs/openid-authentication-2_0-11.html#anchor4
[3] http://groups.google.com/group/openid4java/browse_thread/thread/ 
f96a7b68bb15272d
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: modulus and generator optional in association requests

[Johnny Bufu]

On 20-Mar-07, at 1:36 PM, Granqvist, Hans wrote:

> Once something complex is optional, typically few will
> implement it, which means you can run into the inverse:
> implementations that do supply optional values run into parties
> that cannot treat those values correctly.
>
> This means that if one day the default DH values are regarded
> broken for any reason, it's a hard and cumbersome fix.
>
> There might be other security implications hidden here, not sure.

The fix would be to not use the default values, a feature that should  
be provided by the libraries. So the alternatives are broken  
functionality today vs potential security issues in the future, if DH  
with the default modulus will be broken.

How did you / others deal with this? There are quite a few RPs out  
there who treat these fields as optional, so I'm suspecting it's a  
library issue.


> Btw, what do you mean by "be consistent with section 4.1"?

Section 4.1.  Protocol Messages [2] says:

> Throughout this document, all OpenID message parameters are  
> REQUIRED, unless specifically marked as OPTIONAL.


Johnny

[...]
>> [1] http://openid.net/specs/openid- 
>> authentication-2_0-11.html#anchor19
>> [2] http://openid.net/specs/openid-authentication-2_0-11.html#anchor4
>> [3] http://groups.google.com/group/openid4java/browse_thread/thread/
>> f96a7b68bb15272d

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

Attribute Exchange pre-draft 5

[Johnny Bufu]

Hello list!

Since draft_4 [1] we've done some implementation and testing (as well  
as listened to community's suggestions on related issues), and have  
incorporated some changes into a pre-draft-5. Before publishing it I  
would like to see your comments about them or about other features /  
changes that would be useful in AX.


One feature we didn't figure out yet if its benefits would be worth  
the added complexity:
- in a fetch response, distinguish between attributes
that the user didn't *want* to release and the ones
not supported by the OP.

What do you think?


The changes are:

- Added ax.mode parameters to all messages, to unambiguously identify  
the message types; the values are:
fetch_request
fetch_response
store_request
store_response_success
store_response_failure
This allows implementers to decouple the processing of the underlying  
OpenID Auth message and the extension layer.


- Clarified that the required flags are hints about the RP's  
requirements
meant to help the user decide what data to release
should not be enforced by the OP
RPs should perform validation on the data they receive anyhow
same principle for SREG discussed here:
http://openid.net/pipermail/general/2007-March/001874.html


- Clarified that a fetch response parameter MUST be sent for each  
requested attribute, with an empty value if the user did not supply one.
along the lines of the above, so that the RP can fallback to  
alternative data collection methods


- Clarified that extension namespace aliases should be determined  
dynamically by the party composing the message
discussed here: http://openid.net/pipermail/specs/2007-March/ 
001372.html


Thanks,
Johnny


[1] http://openid.net/specs/openid-attribute-exchange-1_0-04.html
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Server-to-server channel

[Johnny Bufu]

Chris,

On 2-Apr-07, at 11:50 AM, Chris Drake wrote:

> I've also noticed a lot of discussion about attributes, which begs the
> question about how to handle things that change (eg: If I've given out
> my email address to a dozen web sites, and then I change it, how does
> my OpenID server propagate that change to all those sites?)
>
> "User Centric" implies that sites don't store anything about me, and
> that whenever they need to know stuff (eg: my email), they instead ask
> my OpenID server, which returns them the answer (unless I've since
> revoked permission or whatever).  Again - server-to-server (although
> this time in the reverse direction) applies here.

I'm not sure I fully agree on you reasoning above (about sites not  
storing anything about me).

OpenID Attribute Exchange deals with the attribute updates - see the  
"update_url" parameter in fetch requests [1].

The flow would be:

- RP informs the OP where the RP can be updated of changes in  
attribute values
- user changes the value of an attribute
- OP prompts the user with the list of RP who 'registered' for change  
notifications for that attribute
- if the user approves, the OP pushes the new values to the selected  
RPs.

This is basically a push approach, as opposed to the pull approach  
you were suggesting.

The pull approach would add (unneeded) complexity with authorization  
management. Also I don't see how the user-centricity could be  
enforced -- the user / OP can't restrict RPs from storing the data  
they need, once the data is released.


Is there a use case / feature that can be accomplished with the pull  
model, that cannot fit within what I've described above / current AX  
draft?


Johnny


[1] http://openid.net/specs/openid-attribute- 
exchange-1_0-04.html#fetch_request

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

Re: SREG namespace URI rollback

[Johnny Bufu]

Josh,

On 2-Apr-07, at 12:43 PM, Josh Hoyt wrote:

> I'd like to change the simple registration specification so that it
> uses the type URI that is currently in use in at least PIP and
> MyOpenID as the namespace URI instead of defining a new value.
>
> As far as I can tell, the only difference between the 1.0 and 1.1
> simple registration specifications is adding the namespace URI. The
> names and meanings of all of the fields are the same, so there is no
> compatibility issue, and the URI for 1.0 is already reserved (because
> it's used as the Type URI in XRDS documents).
>
> In short, I don't think that the SREG namespace/type URI should change
> until there are incompatible changes to the simple registration
> specification.
>
> So are there any objections to rolling the URI back to
>  from
> ?


I think the missing namespace in SREG1.0 can cause problems; take  
this example:

- RP doesn't support SREG1.0, but does support 2.0 extensions
- RP sees in an XRDS that the OP supports SREG1.* (if the same  
namespace is used for both)
- the OP actually only supports SREG1.0
- RP gets an SREG response without the namespace param
- RP tries to extract SREG1.1, doesn't find a namespace and can't  
handle it

So the OPs that will implement only SREG1.0 will not honor their  
statement in their XRDS files, which would require them to implement  
both versions.


Johnny

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

Re: SREG namespace URI rollback

[Johnny Bufu]

Or even:

> - RP doesn't support SREG1.0, but does support 2.0 extensions
> - RP sees in an XRDS that the OP supports SREG1.* (if the same
> namespace is used for both)
> - the OP actually only supports SREG1.0

- RP sends a SREG1.1 request, but with
openid.ns.some_alias=http://openid.net/sreg/1.0
openid.some_alias.required=...
- OP doesn't understand it

> - RP gets an SREG response without the namespace param
> - RP tries to extract SREG1.1, doesn't find a namespace and can't
> handle it
>
> So the OPs that will implement only SREG1.0 will not honor their
> statement in their XRDS files, which would require them to implement
> both versions.


Johnny

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

Re: SREG namespace URI rollback

[Johnny Bufu]

On 2-Apr-07, at 1:17 PM, Josh Hoyt wrote:

> On 4/2/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
>> I think the missing namespace in SREG1.0 can cause problems; take
>> this example:
>
> I was not proposing that we drop the namespace. Just that we don't
> introduce a new URI when the protocol is otherwise identical, and
> instead just use the existing type URI as a namespace URI.
>
> That is, an SREG 1.1 request looks like:
>
> openid.ns.s=http://openid.net/sreg/1.0&openid.s.nickname=j3h
>
> not:
>
> openid.sreg.nickname=j3h

But the OP in my example doesn't supports only SREG1.0, so it will  
send the latter. And the RP who sent the request (SREG1.1 only)  
assumed that "http://openid.net/sreg/1.0"; in the OP's XRDS meant  
SREG1.1. So even though both parties do the right thing, the  
attribute transfer doesn't happen.

> If you use "sreg" as the namespace alias, SREG 1.1 is identical to  
> SREG 1.0.
>
> Is that clearer?

Sorry - I may be missing something, but I still say the problem  
remains: if a SREG1.1 party builds a message with a namespace alias  
different than "sreg", it can confuse the other party which may be  
expecting specifically "sreg".

Or, put it differently, identifying SREG1.1 with the same URI as  
SREG1.0 would require all RPs and OPs out there to add the namespace  
alias param to their messages, since it is required in OpenID2/ 
SREG1.1 (and that's what the URI also means).


Johnny

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

Re: SREG namespace URI rollback

[Johnny Bufu]

On 2-Apr-07, at 2:08 PM, Josh Hoyt wrote:

> On 4/2/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
>> Sorry - I may be missing something, but I still say the problem
>> remains: if a SREG1.1 party builds a message with a namespace alias
>> different than "sreg", it can confuse the other party which may be
>> expecting specifically "sreg".
>>
>> Or, put it differently, identifying SREG1.1 with the same URI as
>> SREG1.0 would require all RPs and OPs out there to add the namespace
>> alias param to their messages, since it is required in OpenID2/
>> SREG1.1 (and that's what the URI also means).
>
> OpenID 2 messages would use the namespace URI and OpenID 1 messages
> would use the "sreg" prefix. If you do both, all the time, you don't
> have to care which kind of message it is, but I'm not proposing that
> we require doing that.

I agree there is no issue if all parties implement both SREG1.0 and  
SREG1.1.


> If you are making a SREG request, you won't have to care whether it's
> supposed to be 1.0 or 1.1 because they're *the same*.

But they are not the same -- the namespace alias can be different  
than "sreg". Are you suggesting that SREG1.1 must always use the  
"sreg" namespace alias?

> You only have to care whether it's an OpenID 1 or OpenID 2 request  
> so that you can make
> sure that the other end understands the namespacing.

Being OpenID2 and understanding namespacing doesn't imply that the  
party also supports SREG1.1. It may only support SREG1.0, hence only  
accept "sreg" in the place of the namespace alias.


Johnny

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

Re: SREG namespace URI rollback

[Johnny Bufu]

After a chat with Josh, we settled our dispute by agreeing on the  
following:

On 2-Apr-07, at 2:44 PM, Josh Hoyt wrote:
> I think it would be reasonable to always use "sreg", if for no other
> reason than for clarity, but re-using the Type URI as the namespace
> alias instead of creating a new one does not imply that the alias must
> be "sreg" when using OpenID 2.
>
> What if I put my proposal this way:
>
> If Simple Registration is used with OpenID 1, the arguments MUST be
> prefixed with "openid.sreg." If Simple Registration is used with
> OpenID 2, the arguments MUST be in the namespace
> "http://openid.net/sreg/1.0";


The first bit allows a implementation of SREG1.1/OpenID2 to be  
seamlessly used in "compatibility mode" with OpenID1 messages, which  
(together with the last two items in the proposal) would eliminate  
the conflicts I was pointing out.


Johnny

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

Re: Attribute Exchange pre-draft 5

[Johnny Bufu]

On 2-Apr-07, at 12:10 PM, Josh Hoyt wrote:
> On 3/26/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
>> - Added ax.mode parameters to all messages, to unambiguously identify
>> the message types; the values are:
>> fetch_request
>> fetch_response
>> store_request
>> store_response_success
>> store_response_failure
>> This allows implementers to decouple the processing of the underlying
>> OpenID Auth message and the extension layer.
>
> What about using a different namespace URI for each message?
>
> I was thinking:
>  http://openid.net/srv/ax/1.0#fetch_request
>  http://openid.net/srv/ax/1.0#fetch_response
>  http://openid.net/srv/ax/1.0#store_request
>  ...
>
> That eliminates the need for an extra parameter, but makes the auth
> message processing unambiguous. It's also clear to human readers that
> those namespaces are related, since they are in the same document.

The need for a mode param came when, during implementation, having  
decoupled the openid auth message and the extension processing, we  
couldn't distinguish between a fetch response and a store request. So  
the identification bits would be most useful as a message field from  
this point of view.

Other arguments for the original proposal:
- is more inline with the core openid spec
- the extension section in the core spec seems to define the  
extension type URI as the identifier for an extension protocol,  
rather than individual messages within the protocol
- having multiple URIs could lead to confusion as to what OPs should  
put in XRDS files.

Unless there are strong opinions in favor of multiple URIs, I think  
we should go forward with the mode fields.

Johnny

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

Re: Attribute Exchange pre-draft 5

[Johnny Bufu]

I have uploaded changes proposed at the beginning of this thread into  
SVN; if you're up to reading the xml source, it can be viewed here:


To summarize the open issues:

a) ax.mode vs multiple URIs

b) No useful gain for the OP to signal why a (required) attribute was  
not supplied; the RP needs to do data validation anyhow and decide  
what to do next based on the values it has received.

c) How to encode an "unavailable attribute" in a fetch response:
blank value (current)
con: overloads possible legitimate blank values for attributes
pro: unlikely an RP will be satisfied with a blank value for a  
required attribute
omitted attribute
con: RP may not be sure that the OP processed the request

Using the same reasoning as in b), I would say omitting an attribute  
in a response would be just as useful to the RP. Opinions?


Thanks,
Johnny

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

Re: SREG namespace URI rollback

[Johnny Bufu]

David,

On 4-Apr-07, at 11:43 AM, Recordon, David wrote:
>  - Cleanup the newly merged
> http://openid.net/specs/openid-attribute-exchange-1_0-04.html to be  
> more
> concise and list URLs for the existing SREG parameters.  This will  
> thus
> show an easy "upgrade" path between SREG and AX.

I think this is a good idea - to add a note / paragraph outlining  
clearly the "upgrade" path from SREG to AX.

> All through this process it is also important to discuss it on this  
> list
> and drive consensus with the community.  In some senses, I think parts
> of my objections to AX are how it seems like it has just been shoved
> down my throat over the past six months.

Not sure what *exactly* you mean with the above, but at least for the  
least 3 months or so we've been trying to get the community involved  
with AX, on the lists here:

http://openid.net/pipermail/specs/2007-January/001141.html
http://openid.net/pipermail/specs/2007-February/001283.html
http://openid.net/pipermail/specs/2007-March/001385.html

Is there something in particular about the way we handled this that  
doesn't seem right to you? If yes - what exactly do you think should  
be done differently?


Thanks,
Johnny

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

Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)

[Johnny Bufu]

On 4-Apr-07, at 12:18 PM, Recordon, David wrote:
> One thing that I do think would be worthwhile in smoothing more of  
> this
> SREG/AX confusion would be adding SREG support to Sxip's OpenID
> libraries.

This is on the todo list, and judging by the interest showed by some  
contributors could happen any day now.

> Any thoughts on spec consolidation

> I think I'd propose the following:
>  - Remove http://openid.net/specs/openid-attribute- 
> types-1_0-02.html (I
> do not believe OpenID should define its own schema elements for things
> like "First Name" which are not specific to OpenID, defining a URL for
> an OpenID enabled URL for example I think would be fine on OpenID.net)

I understand that point of view and we were looking into determining  
what would be the best place where this spec could live.

However, since the AX's adoption will depend (at least in the  
beginning, before the metadata and automatic acquisition mechanisms  
are finalized) on the participants using the same "names" for the  
attributes they transfer. From this point of view, I believe AX could  
use openid.net's recommendation (if endorsement is too much) to use a  
set of names / URIs for the most commonly transfered attributes.  
(Kind of like what made SREG successful -- having the spec provide / 
something/ for a jump-start).

>  - Merge http://openid.net/specs/identity-attribute- 
> metadata-1_0-01.html
> into http://openid.net/specs/openid-attribute-exchange-1_0-04.html.

I don't think we should merge the AX core with the metadata  
description document. The first one describes the "transport layer"  
for attributes and is reasonably close to a final v1, while the  
metadata is far from being final (no concrete options identified that  
would drive to consensus) and its progress is rather slow.

> and seperating policy from technology?

Not sure what you mean by this.


Johnny

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

Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)

[Johnny Bufu]

On 6-Apr-07, at 10:34 AM, Johannes Ernst wrote:
>> Well, as one of the people that wrote the documents. We decided that
>> having separate documents was better. Thanks for sharing your
>> opinion. I have a different opinion.
>
> For somebody who currently doesn't have an opinion on this subject,  
> could you briefly describe the rationale for your view?

If I'm only interested in moving attributes around (the current case  
of the OpenID libraries), I am not interested at all what the  
semantic of the attributes are, just in moving them from A to B. I'll  
let the parties at the both ends of the transaction look up the  
metadata and handle them based on that.

On the other hand when I read a (new) spec it's a lot easier for me  
if there are clearly outlined components with which I don't  
necessarily have to deal at the same time; especially if the  
components have other uses beside the initial combination.

These two seem to have been the rationale of the recent discussions  
about splitting the OpenID spec into core/discovery/etc., which  
seemed to make sense to a number of people (I'm just not sure if it's  
worth / good tactical move at this stage).


Johnny

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

Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)

[Johnny Bufu]

On 5-Apr-07, at 9:24 AM, Recordon, David wrote:
> I'm all about taking advantage of existing momentum, but I have a hard
> time seeing anyone who cares about AX being unwilling to have this
> discussion as a part of the ID Schemas community.  If there is anyone,
> I'd certainly like to understand the reasons why (beyond it being
> "hard").

I believe a key difference here is between what people would be  
willing to do, and what people actually (will) do. For example:

- I would be willing to go to a rugby game, but I don't know if any  
of my friends are going, so I probably won't go
- most of my friends who like rugby may be thinking and acting the  
same way, or
- most of my friends would go if they knew rugby, but they haven't  
discovered it yet.

 From what I've seen, interesting discussions can be sparkled and  
facilitated by people who do not seem to have been particularly  
interested in a subject beforehand, but happened to be around because  
they shared a broader interest with the community.

We seem to have to potential to build momentum and a critical mass  
for AX and schema discussions here. I propose we continue the  
discussions wherever they happen to take place. If the intensity  
doesn't fade out, having invested a fair bit interest people will be  
more likely to move to a better suited place if asked to.


(Just my thoughts, I am by no means a sociology expert.)


Johnny

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

Re: Logout

[Johnny Bufu]

On 6-Apr-07, at 12:13 PM, Praveen Alavilli wrote:
> well with OpenID atleast, I think we can easily design a logout
> extension, where an RP can register it's logout handler with OP during
> login flow (checkid_immediate/checkid_setup) and the OP could call  
> each
> of the RP's logout handlers (in the browser) that are registered with
> the current session when a user logs out from the OP.

Interesting - what you're describing above looks a lot like the  
update_url feature in AX. Which makes me think that this could  
actually work with what we have today, if we defined a "openid-logout- 
notification" attribute, and the RPs registered for updates when its  
value changes.

> Ofcourse this also requires a new logout mode supported by OP,  
> which an RP can call when a
> user wants to logout from the RP itself. The OP then can provide  
> options
> to the user whether to sign out from one RP or from all.
>
> Any reason why something like this was not incorporated into the  
> specs yet ?

Not sure where this feature would be placed best.


Johnny

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

Re: [Idschemas] Moving AX Forward (WAS RE: SREG namespace URI rollback)

[Johnny Bufu]

On 6-Apr-07, at 4:09 PM, Laurie Rae wrote:

> Seriously though, the issue here isn't really whether or not you  
> and your friends will go to the rugby game,
> it's whether or not the rugby league organizers are trying to get  
> you to go to the rugby game at the appropriate venue.

I would say the venue is not that important; getting into rugby is,  
even on an ice rink if that's where it happens.

> My point? Beyond the relatively inactive state of the ID Schemas  
> list, and the apparent momentum on the OpenID list(s),
> what makes schemas.openid.net (and the OpenID lists) the more  
> appropriate "venue" for this discussion?

Probably nothing;  but I do think momentum is quite important.

> Or, are we just trying to get people to play rugby on an ice rink,  
> just for the sake of putting on a game?

Why not? If they can actually play it on ice for a little while, I  
would hope they will soon realize how much better it can get on grass.


Johnny

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

Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)

[Johnny Bufu]

On 7-Apr-07, at 3:56 AM, Martin Atkins wrote:
> On the other hand, I also think it's a good idea not to modularize too
> early: until there's some implementation experience, it's hard to say
> with certainty what parts make sense as distinct modules. I'm not that
> familiar with the AX stuff yet, but my gut feeling is that it'd be a
> good idea for someone to make an experimental implementation to get  
> some
> implementation experience and then it'll probably be a lot more clear
> where the articulation points are that make spec modularization
> worthwhile. There's little point in debating it at this early  
> stage, in
> my opinion.

We did just that - openid4java supports Attribute Exchange (i.e the  
"transport" layer for attributes), but nothing about the metadata.  
Even if the metadata spec were all figured out, my implementation  
would probably hand over the type URI and the attribute value to the  
layer above for consuming it, which would involve looking up the  
metadata info if necessary.

Josh just started implementing AX [1] and his thoughts were along the  
same lines.


Johnny


[1] http://openid.net/pipermail/specs/2007-April/001520.html
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: SREG namespace URI rollback

[Johnny Bufu]

On 2-Apr-07, at 6:06 PM, Recordon, David wrote:

> Sure, though I think there has also been a desire to do a bit of an

Are we in agreement then (about 1.0 and 1.1 sharing the same type URI)?

I went ahead and implemented SREG in openid4java, and exposed it in  
such a way that the users won't have to know about all these v1.0 /  
1.1 details. But in order for that to work and my implementation to  
be compliant, the type URI of SREG 1.1 needs to change as proposed by  
Josh in the next (final?) draft.

Thanks,
Johnny

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

Re: PROPOSAL schema.openid.net for AX (and other extensions)

[Johnny Bufu]

On 10-Apr-07, at 12:01 AM, Rowan Kerr wrote:
> While at Standard, I ended up hosting our own schema so we would have
> a consistent set to work from and refer our partners to. It's based
> on attributes from an older revision of AX but the metadata should be
> pretty close to the existing format.
> The schema is posted here: http://idschema.standardinteractive.com/

I've uploaded the initial set to into the attribute_properties  
repository; you can browse the sources here:




Johnny

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

Attribute Exchange draft 5

[Johnny Bufu]

Thanks everyone for the good feedback and discussions during the last  
week. I went through the messages and added clarifications and  
modifications for the issues where there seemed to be consensus.

Since there were a handful of changes, I've tagged the result and  
asked David to put draft 5 up on openid.net, so we can use it as a  
base for sorting out the remaining issues. You can see AX draft 5 here:

http://openid.net/specs/openid-attribute-exchange-1_0-05.html


The outstanding issues so far (and today's change log) are summarized  
below. Please voice your opinion about them! (Separate threads for  
each discussion would help with tracking.)

If I've missed anything or there are new issues and feedback please  
bring that up, too.


==

How does the RP request all the values available at the OP for an  
attribute?
Options:
magic count value = -1?
others?


The OpenID realm has no meaning in a store request; need to be  
clarified? Suggestions?


Todo: Example for the SReg to AX upgrade path.


Newlines are not allowed in openid field values; how do we deal with  
newlines in attribute values?


How can the RP determine the maximum value length that an OP will  
support for a particular attribute?


What is the maximum length of an alias string that an RP can expect  
an OP to support?


How does the RP determine the schema of the provider to know what to  
ask for?


OP is not required maintain preserve the order of the attribute  
values internally and in a fetch responses; does it needs  
clarification in the spec?


Is it legal for the values of a multi-valued attribute to be bytewise  
identical (.fav_movie.1=X, .fav_movie.2=X)?


How can the RP determine the maximum value count that an OP will  
support?


What is the locale of the status messages in the protocol?

==

CHANGELOG:

Removed OpenID error responses reference - AX doesn't actually use them.

Added clarification note about OPs dereferencing the attribute URIs  
in order to dynamically assist users.
Mark Wahl's issue #2: http://openid.net/pipermail/specs/2007-April/ 
001565.html

Refactored required / if_available description to use the same  
phrases; dropped mention of 'error condition'.

Modified count and blank attribute values:
- OP may return less than the number of requested attributes
- OP must not return a .value. field if a value was not provided
- count=0 is allowed to explicitly state that no value was provided  
for an attribute
- for count=1 both response formats (with or without count) are allowed
http://openid.net/pipermail/specs/2007-April/001430.html
http://openid.net/pipermail/specs/2007-April/001469.html

update_url in fetch requests:
- consequent updates use the OpenID protocol
- must match the realm in the OpenID message
- use of 404 for unsubscribing

Clarified the intent / usage of store requests.

More store requests clarifications:
- error message intended to be presented to the user
- alias used to associate values with type URIs within the message
- rearange the intro paragraphs

Disallowing periods in attribute aliases.

==


Thanks,
Johnny

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

Re: Problem with check_authentication

[Johnny Bufu]

On 13-Apr-07, at 8:53 AM, Kevin Richards wrote:

> In the spec it shows an example of the 'signed' fields returned from a
> check_id_* request as "mode,identity,return_to". However if you try  
> and do a

I had a quick look at the spec and didn't this example. Can you  
please point to it?

Currently the spec requires claimed_id, identity, op_endpoint,  
return_to, response_nonce, assoc_handle to be signed.

> check_authentication it will always fail because the mode will  
> always be
> check_authentication not.

Yes, including the mode in the signed list will break the direct  
verification (unless the OP compensates for it).


Johnny

___
specs mailing list
[EMAIL PROTECTED]
http://openid.net/mailman/listinfo/specs

encoding newlines in attribute values

[Johnny Bufu]

The core spec doesn't allow newline characters ("\n") in any openid.*  
values. Currently, Attribute Exchange doesn't specify a way to encode  
newlines in attribute values.

At a minimum, we could specify a way to escape just the \n character.  
Other option would be to do something more generic, e.g. URL-encoding  
the values.

What do you think would work best?


Johnny

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

Re: encoding newlines in attribute values

[Johnny Bufu]

On Apr 19, 2007, at 10:46 AM, Josh Hoyt wrote:
> Each attribute already has to define its encoding rules and data-
> type. The mechanism for encoding a newline can be part of this
> encoding, if newlines are allowed in the value. Once there is one
> attribute that has a defined encoding for newline, when new
> attributes are defined, they can re-use this encoding. Does that
> sound reasonable?

So are you proposing that AX only accepts strings without newline  
characters in them, and the encoding to such a string should be  
handled by the parties who actually consume the attributes, according  
to the type / metadata specs?

This would be nice and simple for the AX itself, however it would  
require everyone defining attributes to also define a 'encoding to  
strings without newlines' for them.


Johnny


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

Re: encoding newlines in attribute values

[Johnny Bufu]

On 20-Apr-07, at 11:18 AM, Dick Hardt wrote:
> To expand on that and include Mark Wahl's proposal about locale  
> encoding[1] in a standard way for attributes so that the libraries  
> can do the right thing 99% of the time.
>
> I would propose that AX data have a default encoding that can be  
> overrode by the attribute metadata. The default would be:
>
> URL encoding for text data
> escape sequence for locale using mechanism in RFC 3866
> escape sequence to indicate binary data that is then base64 encoded

Does this work for everyone? If there are no issues, I'd like to  
summarize it in the spec so that:

- a "default encoding" is defined as described above
- attribute specific encodings can be used, and their presence is  
signaled with an escape sequence similar to the ones used in Mark's  
language tags proposal.

The default encoding would then be applied only when a attribute- 
specific encoding was not used.

Agreed?


Johnny


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

Re: encoding newlines in attribute values

[Johnny Bufu]

Hans,

On 30-Apr-07, at 9:22 AM, Granqvist, Hans wrote:
> Just so we're all on the same page: Can you post a link
> to the referenced proposal?

Mark has announced it here on the list:

http://openid.net/pipermail/specs/2007-April/001630.html


Johnny


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

Re: encoding newlines in attribute values

[Johnny Bufu]

On 27-Apr-07, at 3:46 PM, Johnny Bufu wrote:
> The default encoding would then be applied only when a attribute-
> specific encoding was not used.

With help from Mark Wahl I've put this into the spec and wrapped up  
the remaining issues.

The latest version is in SVN here:
http://openid.net/svn/listing.php?repname=specifications&path=% 
2F&rev=0&sc=1

And I've also uploaded html and text versions for convenience:

http://openid.net/svn/specifications/attribute_exchange/1.0/trunk/ 
openid-attribute-exchange.txt
http://openid.net/svn/specifications/attribute_exchange/1.0/trunk/ 
openid-attribute-exchange.html


Please have a look and point out what still needs to be fixed. I'd  
like to tag draft6 at the end of the week so that we can reference it  
easier during IIW.


Thanks,
Johnny


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

Re: Final outstanding issues with the OpenID 2.0Authenticationspecification

[Johnny Bufu]

David,


On 18-May-07, at 11:09 AM, Recordon, David wrote:
> Hey Marius,
> Good point, committed a patch so please review! :)


On 18-May-07, at 11:08 AM, [EMAIL PROTECTED] wrote:
> +  
> + As discussed in the  +target="compat_mode">OpenID Authentication 1.1
> +Compatibility mode section, these discovery tags
> +are not the same as in previous versions of the protocol.
> +While the same data is conveyed, the names have  
> changed which
> +allows a Relying Party to determine the protocol version
> +being used.  A Relying Party MAY encounter a Claimed  
> Identifier
> +which uses HTML-Based Discovery to advertise both  
> version 1.1
> +and 2.0 Providers.
> +  

I believe we should make the above a bit more 'normative' for what  
the discovery elements should contain, rather than just warning RPs  
about what they MAY encounter. The qualifier for backwards  
compatibility is SHOULD / RECOMMENDED through the rest of the spec,  
so I propose we replace your text with:


> For backwards compatibility, if supported by the OP, the HEAD  
> section of the document SHOULD also include OpenID 1.x discovery  
> elements:
>
>   A  tag with attributes "rel" set to "openid.server" and  
> "href" set to an OP Endpoint URL
>   A  tag with attributes "rel" set to "openid.delegate" and  
> "href" set to the end user's OP-Local Identifier
>
> The protocol version when HTML discovery [...] an OpenID 1.x  
> endpoint is "http://openid.net/signon/1.1";.


Johnny

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

Re: directed identity + HTML discovery: is this right?

[Johnny Bufu]

On 18-May-07, at 2:19 PM, Peter Watkins wrote:
> [...]
> Would we put the OP-Local Identifier in both openid.claimed_id *and*
> openid.identity?

The user/OP can choose to send the local_id as the claimed  
identifier, or any other claimed identifier that delegates to the  
local_id sent as openid.identity in the response.

> I'm confused about section 10.1's discussion of openid.claimed_id:  
> "Note:
> The end user MAY choose to use an OP-Local Identifier as a Claimed
> Identifier." This reads like a slight restatement of the earlier  
> language
> suggesting users' choosing their own OP-Local Identifier (section  
> 10, "If
> the relying party requested OP-driven identifier selection... the  
> OP SHOULD
> allow the end user to choose which Identifier to use."), but it's  
> subtly
> different and suggests two things to me:
>  1) a user interface requirement on the OP side (the user cannot  
> choose
> an identifier after the RP authentication request and before the
> OP's authentication response unless the OP has some sort of user
> interface to allow the user to make such a choice, so this  
> looks like
> it might be equivalent to something like  "the OP MUST allow  
> the end
> user to choose an OP-Local Identifier for use in the response"

It doesn't have to be a MUST. If the user has only one such  
identifier at the OP, there is no choice to be made.

>  2) that the OP might return a Claimed ID of the user's choosing  
> even if
> the RP did not send the identifier_select identity request param
> Should this read "The OP MAY allow the end user to choose an OP-Local
> Identifier as a Claimed Identifier if there are multiple  
> Identifiers for
> which the end user is authorized to issue authentication responses  
> and the
> relying party requested OP-driven identifier selection by setting
> "openid.identity" to "http://specs.openid.net/auth/2.0/ 
> identifier_select""

The user/OP can choose a OP-local identifier as a claimed identifier  
(different than the one in the request) even if there is only one  
available. Also, "for which the user is authorized to issue  
authentication responses" is part of the definition of an OP-local  
identifier, so I wouldn't put that in.

> Also, this "MAY" language suggests that openid.claimed_id in the  
> response
> can itself be an OP-Local Identifier and differ from the  
> openid.claimed_id
> value that the RP passed in the authentication request. Is that  
> correct?

Yes. This is reinforced in 10.1, openid.identity :

Note: Relying Parties SHOULD accept and verify assertions about
Identifiers for which they have not requested authentication. OpenID
Providers MAY assist the end user in selecting the Claimed and
OP-Local Identifiers about which the assertion is made.

> In an OpenID 2.0 transaction, if openid.claimed_id and  
> openid.identity in
> the response differ, which value is the RP to use as the user's URL?

The claimed identifier (after verification, of course).


> Could the draft be updated to clarify the uses of these two  
> response items?

I believe this is covered in 11.2 Verifying Discovered Information.


Johnny

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

Re: clarifying section 11.2 in draft 11 for HTML discovery?

[Johnny Bufu]

On 24-May-07, at 8:19 AM, Peter Watkins wrote:

> Section 11.2 states
>
> "If the Claimed Identifier was not present in the request  
> ("openid.identity" was "http://specs.openid.net/auth/2.0/ 
> identifier_select"), the Relying Party MUST perform discovery on  
> the Claimed Identifier in the response to make sure that the OP is  
> authorized to make assertions about the Claimed Identifier."
>
> It then goes on to illustrate how an XRDS document could be constucted
> for verifying an OP's authority in such a post-assertion discovery
> process. It would seem logical that HTML discovery should be an option
> here, and that a confirming HTML document would include the usual LINK
> elements. For instance, if the OP Endpoint URL was https:// 
> id.plumbers.co/
> and the identifier in the assertion was https://id.plumbers.co/ 
> users/1234
> then HTML discovery for 11.2 would work by requesting the URL
> https://id.plumbers.co/users/1234 and verfiying that its HREF for
> openid2.provider was "https://id.plumbers.co/"; and the HREF for
> openid2.local_id was "https://id.plumbers.co/users/1234";.
>
> But as it stands, only XRDS (XRI/Yadis?) post-assertion discovery  
> is discussed.
>
> Shouldn't the spec clarify what is required for an HTML discovery to
> uphold an assertion that triggers 11.2's discovery process?

Section 11 is, again, about how RPs consume the assertions;  
specifically, it explains how the mappings between discovered  
information and assertion data must be checked.

Discovery is covered in detail in section 7.3 (and referenced from  
section 11). If we go into too many details about discovery in  
section 11, it may lead readers to believe that is the authoritative  
section about discovery, and possibly overlook important items  
specified in section 7.3 (not to mention adding to the perceived  
"complexity" of the spec...) That's why a short, non-normative  
example was preferred in that place.


Johnny

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

attribute exchange value encoding

[Johnny Bufu]

Hello list,

While at IIW, I asked around what people thought about the encoding  
mechanisms we've added recently, in order to allow for transferring  
any data types. The consensus was that everyone would prefer  
something simpler and lighter.

So I've rewritten the encoding section, such that:

- for strings, only the newline (and percent) characters are required  
to be escaped,
   (to comply with OpenID's data formats), using percent-encoding;

- base64 must be used for encoding binary data, and defined
   an additional field for this:
openid.ax.encoding.=base64


Please review section 3.3 Attribute Values to see if there are any  
issues.


One remaining question is about the choice of encoding for strings.  
Percent-encoding (RFC3968) seems the simplest from a spec  
perspective, however some libraries provide (better) support for the  
older URL-encoding (RFC1738), which throws '+' characters into the  
mix. Which do you think would work best for implementers, users, and  
would cause less interop problems?


Johnny

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

Re: attribute exchange value encoding

[Johnny Bufu]

On 24-May-07, at 5:15 PM, Johnny Bufu wrote:

> Please review section 3.3 Attribute Values to see if there are any
> issues.

Of course it helps if there's a link to click on... I missed it in  
the previous message:

<http://openid.net/svn/filedetails.php?repname=specifications&path=% 
2Fattribute_exchange%2F1.0%2Ftrunk%2Fopenid-attribute- 
exchange.html&rev=0&sc=0>


Johnny

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

Re: Realm spoofing spec patch

[Johnny Bufu]

Josh,

On 24-May-07, at 4:19 PM, Josh Hoyt wrote:

> Please review the additions. If you'd like to see the
> specific changes, you can look at the diffs in revision control[3].

Looks good to me. One minor issue about the wording - we have now two  
"return URL verifications": one done by the OP and a totally  
different one done by the RP. Would it make sense to call this new  
one something different, e.g. "RP endpoint verification" (or  
validation)?


Johnny

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

Re: Realm spoofing spec patch

[Johnny Bufu]

On 24-May-07, at 5:54 PM, Recordon, David wrote:

> I guess since we're unable to fully resolve this issue from a  
> technical
> perspective, and no I don't have a better technical solution, I'm
> wondering if this should actually be an extension to the core protocol
> versus seeming like a resolution to the problem when it really doesn't
> completely solve it.

-1

An extension is totally optional. On the other hand, when I implement  
a spec I treat all SHOULDs as MUSTs by default, and only examine them  
if I can't deal with something.


The main issue with this attack I believe was the OP making a false  
statement to their users, thus compromising their trust.

Even with the SHOULDs, the OPs have the means to decide how they  
interact with their users. If this results in not granting access to  
unverified RPs, the OP can say "well, the RP you're trying to go to  
really SHOULD implement RP discovery".

With an extension the OP's statement would be "we're using this  
extension and can't let you go to this RP because they don't  
implement it and we can't verify their endpoints".


Having said that, I would certainly like some of these SHOULDs to be  
turned into MUSTs if doing so doesn't lead to other issues  
(deployments, etc.).


Johnny

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

Re: attribute exchange value encoding

[Johnny Bufu]

Hi Drummond,

On 25-May-07, at 8:55 PM, Drummond Reed wrote:
>> One remaining question is about the choice of encoding for strings.
>> Percent-encoding (RFC3968) seems the simplest from a spec
>> perspective, however some libraries provide (better) support for the
>> older URL-encoding (RFC1738), which throws '+' characters into the
>> mix. Which do you think would work best for implementers, users, and
>> would cause less interop problems?
>
> FWIW, encoding "+" can be a hassle as it's a legal character in  
> media type
> values and is also sometimes used for spaces. I'd vote for pure  
> RFC3986
> percent-encoding.

Simplicity was the reason for requiring percent-encoding for only two  
characters.

Then it was brought to my attention that implementers may be tempted  
to use the more readily-available functions for URL-encoding, which  
do share the percent-encoding part with what's specified currently in  
AX, but will break other characters.

This is why I wanted to know what others thought about this being a  
potential problem.


Another option would be to define an equally simple but not-so- 
popular encoding, so that implementers are forced to write the  
required 5-line encoding routines themselves; but the unfamiliarity  
of it would add to the (perceived?) complexity of the spec.

I'm trying to find a good balance between simplicity, providing  
enough features, and avoiding deployment problems; so all feedback is  
highly appreciated!


Thanks,
Johnny

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

Re: Re-defining the Key-Value format (was: attribute exchange value encoding)

[Johnny Bufu]

Hi Claus,

On 28-May-07, at 5:55 AM, Claus Färber wrote:

> Johnny Bufu schrieb:
>> So I've rewritten the encoding section, such that:
>>
>> - for strings, only the newline (and percent) characters are required
>> to be escaped,
>>(to comply with OpenID's data formats), using percent-encoding;
>
> This means that '%' characters need to be encoded up to three times:

I'm not sure I follow your reasoning all the way; please see my  
comments below and point where I'm wrong.

> For example:
>
> User name: 100%pure
>
> Embedded in an URI that is the value of the attribute:
>http://example.com/foo/100%25pure

This encoding happens outside of the OpenID / AX protocols. There's  
nothing we can do in the specs about it, if the value of an attribute  
is an URI like http://example.com/foo/100%25pure.

 From the OpenID / AX point of view, I view the above as an unencoded  
% character (AX doesn't know in this case that the payload is an  
URI); it's up to whoever consumes the attribute value to handle it  
properly.


> Encoded for AX using Key-Value Form Encoding  (OID 2, 4.1.1.)
>openid.ax.foo.uri:http://example.com/foo/100%2525pure

AX has nothing to do directly with key-value encoding. I see no  
reference to percent-encoding from OpenID2's section 4.1.1.

But yes, using the AX 3.3.1 Default Encoding of a String Value [1],  
if user_name=100%pure the field in an key-value representation would be:

openid.ax.foo.value=100%25pure


> Encoded for AX using HTTP Encoding (OID 2, 4.1.2.)
>openid.ax.foo.uri=http%3A//example.com/foo/100%2525pure

Yes, there would be a double-encoding of the % char, one done by AX  
3.3.1, and another x-www-form encoding as required by OpenID 4.1.2  
for indirect messages.


> I don't think it's a good idea to introduce a solution to the "\n"
> problem in AX only. It should be part of the base spec (OpenId 2
> Authentication).

What do you see as pros / cons for each proposed solution?


> What about changing section 4.1.1. from:
>
>  A message in Key-Value form is a sequence of lines.  Each
>  line begins with a key, followed by a colon, and the value
>  associated with the key.  The line is terminated by a
>  single newline (UCS codepoint 10, "\n"). A key or value
>  MUST NOT contain a newline and a key also MUST NOT contain
>  a colon.
>
> to (wording adapted from RFC 2822):
>
>   A message in Key-Value form consists of fields composed of
>  a key, followed by a colon (":"), followed by a value, and
>  terminated by a single LF (UCS codepoint 10, "\n").
>
>  The key MUST be composed of printable US-ASCII characters  
> except
>  ":" (i.e. characters that have values between 33 and 57, or
>  between 59 and 126, inclusive). The key MUST NOT start with
>  a '*' (codepoint 32).
>
>  The value MUST be composed of a sequence of characters  
> encoded
>  as UTF-8. If an extension to this specification allows values
>  that contain LF (UCS codepoint 10, "\n") characters, these LF
>  (UCS codepoint 10, "\n") characters MUST be encoded as a
>  sequence of LF, '*', ':' (UCS codepoints 10, 42, 32,   
> "\n*:").
>
> [Unlike the suggested %-encoding, this encoding is compatible with
> the current spec as long as LF characters are not actually allowed
> within the value.

What makes the proposed percent-encoding incompatible with the  
current OpenID spec?


> It's similar to the RFC 2822 folding mechanism but folding is only
> allowed (and mandated) where a LF is to be encoded. Further, the
> continuation line is compatible with the key-value format,  
> using '*'
> as a pseudo key value.]
>
>  If an extension to this specification needs to allows binary
>  data in values, i.e. if it allows arbitrary bytes not to be
>  interpreted as UTF-8 characters, it MAY use Base64  
> []
>  encoding for the specification of the format of that value.

I would be (mildly) ok with dealing with newline escaping in the core  
if others agree, but:
- it does add some extra stuff, which some may not like / approve
- it would add another item on the 'compatibility list', and another  
thing that OpenID 1/2 implementations would need to deal with twice
- not sure what would be the net advantage of having it there (aside  
from having consistency across all extensions).

> [Note: Base64, is quite efficient when it comes to encoding the
> message in HTTP Encoding (OID 2, 4.1.2.). Unencod

Re: attribute exchange value encoding

[Johnny Bufu]

Hi Gouping,

On 28-May-07, at 9:22 PM, Guoping Liu wrote:
> I have a couple comments on Section 3.3.2 Default Encoding of a Binary
> Value.
>
> First, the character set of standard Base64 encoding is not URL-safe.
> Specifically, '+', '/' and '=' need to be URL-encoded. So, we need to
> URL-encode the value after base64 encoding.

I believe the HTTP encoding [1] in the OpenID spec will take care of  
this part, i.e. before putting the OpenID + AX message on the wire,  
the OpenID layer has to HTTP-encode it.

> Secondly, different platforms may have different binary formats for a
> given type of objects. There may be interoperability issues with  
> binary
> values across different platforms. We may want to use a string
> representation of an object instead of its binary representation, like
> in any XML document. For example, for an integer value 1234 of  
> attribute
> x we have openid.ax.x=1234. With this we will not need base64  
> encoding.
> But, we will still need URL-encoding.

The attribute metadata can be used to define attribute-specific  
encodings, which should deal with issues like this.

The AX protocol has to stay simple (that was overwhelming feedback  
I've received at IIW). The base64 encoding is there as a convenience:  
if a number of OPs and RPs agree on an attribute type (the classical  
example being an avatar image) but don't want to go to the trouble of  
publishing metadata information, they can use AX's base64 support for  
transferring it. And yes, I'd expect numeric values to be transferred  
as strings in >90% of the cases.


Johnny

[1] http://openid.net/specs/openid-authentication-2_0-11.html#anchor4

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

Re: Re-defining the Key-Value format

[Johnny Bufu]

Hi Claus,

On 28-May-07, at 3:58 PM, Claus Färber wrote:
> Johnny Bufu schrieb:
>>> Encoded for AX using Key-Value Form Encoding  (OID 2, 4.1.1.)
>>>openid.ax.foo.uri:http://example.com/foo/100%2525pure
>>
>> AX has nothing to do directly with key-value encoding. I see no
>> reference to percent-encoding from OpenID2's section 4.1.1.
>
>> But yes, using the AX 3.3.1 Default Encoding of a String Value [1],
>> if user_name=100%pure the field in an key-value representation  
>> would be:
>>
>>  openid.ax.foo.value=100%25pure
>
> This looks wrong. In Key-Value Form, it would be:
>
>  ax.foo.value:100%25pure
>
> (A colon, no "openid." prefix.)

You're right, of course; I wasn't paying attention to prefixes /  
separator, just to the encoding part.


> In HTTP Encoding, it would be:
>
>  openid.foo.value=100%2525pure
>
> (First encoding from AX, second encoding from HTTP Encoding.)

Ok, so we're on the same page here: two encodings done by OpenID and  
AX, and one more by the application layer above.


>>> I don't think it's a good idea to introduce a solution to the "\n"
>>> problem in AX only. It should be part of the base spec (OpenId 2
>>> Authentication).
>>
>> What do you see as pros / cons for each proposed solution?
>
> AX is not the only OpenID extension that might need to encode "\n"
> characters.
>
> If other specifications need to encode "\n" characters, it is  
> easier to
> write such specifications if the base specification (OpenID 2.0
> Authentication) provides the encoding. It is also less likely that
> writers of such specifications invent their own ad-hoc encoding (or  
> miss
> the problem at all).
>
> The same is true for binary data: If the OpenID 2.0 specification
> RECOMMENDs base64, it's less likely that authors of extension specs
> invent their own encoding (which might be incompatible with software
> that expects UTF-8 and/or produces larger messages in HTTP Encoding.)

I agree with these points; the only drawback would then be having  
another thing added to the core spec and the difference from OpenID1.


>>> What about changing section 4.1.1. from:
>>>
>>>  A message in Key-Value form is a sequence of lines.  Each
>>>  line begins with a key, followed by a colon, and the value
>>>  associated with the key.  The line is terminated by a
>>>  single newline (UCS codepoint 10, "\n"). A key or value
>>>  MUST NOT contain a newline and a key also MUST NOT contain
>>>  a colon.
>>>
>>> to (wording adapted from RFC 2822):
>>>
>>> A message in Key-Value form consists of fields composed of
>>>  a key, followed by a colon (":"), followed by a value, and
>>>  terminated by a single LF (UCS codepoint 10, "\n").
>>>
>>>  The key MUST be composed of printable US-ASCII characters
>>> except
>>>  ":" (i.e. characters that have values between 33 and 57, or
>>>  between 59 and 126, inclusive). The key MUST NOT start with
>>>  a '*' (codepoint 32).
>>>
>>>  The value MUST be composed of a sequence of characters
>>> encoded
>>>  as UTF-8. If an extension to this specification allows  
>>> values
>>>  that contain LF (UCS codepoint 10, "\n") characters,  
>>> these LF
>>>  (UCS codepoint 10, "\n") characters MUST be encoded as a
>>>  sequence of LF, '*', ':' (UCS codepoints 10, 42, 32,
>>> "\n*:").
>>>
>>> [Unlike the suggested %-encoding, this encoding is compatible  
>>> with
>>> the current spec as long as LF characters are not actually  
>>> allowed
>>> within the value.
>>
>> What makes the proposed percent-encoding incompatible with the
>> current OpenID spec?
>
> You can't use it as an encoding for _all_ Key-Value-Form messages,
> including those already specified in the base specification, as it
> encodes the '%' character differently:
>http://example.com/f%E4rber>
> vs.
>http://example.com/f%25E4rber>.
>
> If you want to change the encoding in the base specification (which I
> want to do), it better be identical for all characters except LF.

So you were considering it for encoding / escaping the newlines in  
the OpenID spec / key-value form encoding. If we went wit

Re: Specifying identifier recycling

[Johnny Bufu]

On 30-May-07, at 6:21 PM, Martin Atkins wrote:

> John Panzer wrote:
>>
>> Has there been a discussion about an extension to map to/from i- 
>> numbers
>> via AX?  If there were a generic attribute you could stuff an i- 
>> number
>> or a hash of an internal ID in there to help solve the disambiguation
>> problem.  Alternatively it'd be nice to have a way to ask when the
>> account was created, if the OP is amenable.
>>
>
> If you're going to use i-numbers, then there's no reason at all not to
> use the XRD CanonicalID element. The same mechanism that's used to map
> i-names onto i-numbers can also be used to map URLs onto i-numbers, or
> URLs onto other URLs.
>
> I'm sure Drummond can talk in more detail about this. We did  
> discuss it
> briefly at IIW, but once the majority had decided that the fragment
> approach was the way to go we didn't get a chance to investigate this
> further.

We did look at this (with Drummond) in December. The bottom line is  
that it can't be done easily - a mechanism similar to XRI's canonical  
ID verification would have to be employed, to confirm that the i- 
number actually 'belongs' to the URL on which discovery was  
initiated. (Otherwise anyone could put any i-number in their URL- 
based XRDS files.)


Johnny

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

Re: Specifying identifier recycling

[Johnny Bufu]

On 30-May-07, at 1:28 PM, Josh Hoyt wrote:

> How should the discovery process work?
> How should fragments work with delegation (both as the claimed
> identifier and the provider-local identifier)?

Here's how I see the fragments approach working:

a) Discovery: strip the fragment from the user-supplied identifier  
before initiating discovery.

b) Auth response: if a different op-local identifier is not  
specified, the claimed identifier sans fragment MUST be used as the  
value for openid.identity.

c) Verification of discovered information against auth response fields:
strip_fragment(openid.claimed_id) == discovered claimed id
openid.identity == discovered op-local id (no change)

d) Identifying the user:
openid.claimed_id in auth response SHOULD be used as a key (no change)
strip_fragment(openid.claimed_id) MAY be used as user-visible id


 From your list of issues:

> 1. Using a URI fragment with a uniquifying value:
>
>   * Potential problems with initiation and discovery

No issues with the proposal above (but please think over and confirm!)

>   * Potential problems with inconsistent behaviours on OpenID 1 sites

OPs should send claimed IDs with fragments only for OpenID2 messages.

>   * URLs that user see may be ugly or inconsistent across sites (if
> some relying parties do and others do not strip the fragment
> before display)

Maybe enforce that fragments SHOULD NOT be used for display?

>   * There is no difference between different versions of a
> *user-displayed* identifier (users can't tell if a reference to a
> URL in the wild belongs to the current ownder of a URL or another
> user).

Not sure how RPs can be notified and then how they should act when an  
identifier gets recycled. Do we need to deal with this?

Here are three scenarios and what would happen in each case:

--

no delegation:

user-supplied id: http://example.com/user#1234
or:
user-supplied id: http://example.com/user

discovery:
claimed id = http://example.com/user
op-local id = http://example.com/user

auth request:

openid.claimed_id=http://example.com/user
openid.identity=http://example.com/user

auth response:

openid.claimed_id=http://example.com/user#1234
openid.identity=http://example.com/user

--

delegation (1):

user-supplied id=http://blog.com/
http://blog.com/  delegates to  http://op.com/user#4567

discovery:

claimed id=http://blog.com/
op-local id=http://op.com/user#4567

auth request:

openid.claimed_id=http://blog.com/
openid.identity=http://op.com/user#4567

auth response:

openid.claimed_id=http://blog.com/
openid.identity=http://op.com/user#4567

--

delegation (2):

user-supplied id=http://blog.com/#1234
http://blog.com/  delegates to  http://op.com/user#4567

discovery:

claimed id=http://blog.com/
op-local id=http://op.com/user#4567

auth request:

openid.claimed_id=http://blog.com/
openid.identity=http://op.com/user#4567

auth response:

openid.claimed_id=http://blog.com/#1234
openid.identity=http://op.com/user#4567

- a binding between http://op.com/user#4567 and the http://blog.com/ 
#1234 claimed id must be done somehow by the OP
- do we need to support this use case?

--


Johnny


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

Re: Specifying identifier recycling

[Johnny Bufu]

Josh,

On 30-May-07, at 1:28 PM, Josh Hoyt wrote:

> Providers can also provide a redirect from the general form of the
> identifier to the current version of the identifier so that users do
> not need to remember or type the uniquified version. This is pretty
> much equivalent to the fragment scheme, except:
>
>   * It does not require spec changes (and is backwards-compatible!)
>
>   * The uniquifying component is user-visible
>
> I'd like to hear opinions on whether this unique-URL solution is good
> enough to solve the problem.

If Dick's original assessment on the requirements is right:

> Motivating use case:
>   For large OPs, user identifier namespace is a scarce resource and
> they need to be able to recycle human readable identifiers
>
> Design Considerations:
>
>   + Existing identifiers continue to work
>   + A human readable, memorable identifier can be entered by the user
> and displayed to other users
>   + A globally unique identifier is user by RPs that is different for
> different users of the same human readable identifier

... by pushing the uniquifying part into the displayed URL the  
displayed identifiers become unfriendly / human-unreadable.


It would be great the ones who consider identifier recycling a show  
stopper agreed that your proposal is good enough.


Johnny

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

Re: attribute exchange value encoding

[Johnny Bufu]

On 29-May-07, at 2:33 AM, Claus Färber wrote:

> Johnny Bufu schrieb:
>> The attribute metadata can be used to define attribute-specific
>> encodings, which should deal with issues like this.
>
> Ah, so the _usual_ way is that the metadata (Can this be renamed to
> "datatype definition"? "metadata" is very misleading.) defines the
> encoding.

That would be the preferred way, yes. "Metadata" seems to make sense  
to most people involved in the schema effort, because it can contain  
other stuff beside data type description. But this is a work in  
progress, so if you're interested and want to make your case I'm sure  
you'll be most welcome on the idschema list:

[EMAIL PROTECTED]
http://mail.idcommons.net/cgi-bin/mailman/listinfo/idschemas

> For binary data, it will be base64Binary or hexBinary as
> defined in XML schema. Correct?

Yes, whatever encoding is defined in the metadata document.

>> The AX protocol has to stay simple (that was overwhelming feedback
>> I've received at IIW). The base64 encoding is there as a convenience:
>> if a number of OPs and RPs agree on an attribute type (the classical
>> example being an avatar image) but don't want to go to the trouble of
>> publishing metadata information,
>
> In other words: The metadata is implicitly agreed upon by the parties
> involved. If they can agree on the meaning and the base format  
> (integer,
> string, *binary,...) they can also agree on an encoding (e.g. agree on
> base64Binary instead of *binary).
>
> So I don't think AX needs means to flag base64 data. The parties
> involved should know when base64Binary or hexBinary is used by out of
> band information (metadata/datatype definition or mutual agreement).

I see your point - if the parties involved agree on the attribute  
type and (implicitly) on its data format, they can / should go one  
step further and agree on the encoding as well. And eventually the  
prevailing method would be to programatically determine the encoding  
from the metadata documents.

> In other words, AX should just restrict values to UTF-8 strings and
> recommend base64Binary (or hexBinary) for datatypes (datatypes, not
> data!) that can't be represented as UTF-8 strings.

Yes, that would work too; it would be basically AX draft-5 plus  
disallowing newlines in attribute values in order to comply with the  
underlying OpenID data formats.

If there's agreement that encoding is more tightly coupled with the  
attribute types and their metadata definition, we can just reference  
that in the AX spec.


Johnny

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

Re: Review of Yadis section in XRI Resolution 2.0 WD11

[Johnny Bufu]

Hi Drummond,

On 30-May-07, at 10:45 PM, Drummond Reed wrote:
> To make this new section easy to review, we've put it on the XRI TC  
> wiki at:
>
>   http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris
>
> It's pretty short and sweet, mostly because XRDS documents and  
> their context
> and usage are defined elsewhere in the spec. So this section just  
> defines
> the URL-based discovery protocol, which is the meat of the Yadis  
> 1.0 spec.
> The wording has been restructured slightly to fit the OASIS spec  
> format,
> however the only normative change was to make the recommendation to  
> include
> the application/xrds+xml Accept header in the HEAD or GET request a  
> SHOULD
> instead of a MAY.

It looks really nice and clean to me :-) but I spotted two issues:

1) The final GET for the XRDS document MUST have the application/xrds 
+xml accept header in both 8.1 and 8.2:

> The requesting agent MUST then request the XRDS document using an  
> HTTP(S) GET with an Accept header specifying the content type  
> application/xrds+xml.

(I take it that the MUST applies to everything that follows in the  
sentence.)
This does not seem to be specified in Yadis.


2) Fallback from HEAD to GET:

8.1:
> If the response includes neither option above, discovery of an XRDS  
> document is not available for the target resource.

Yadis 6.2.8:
> If the response to an HTTP HEAD request does not contain a Yadis  
> Resource Descriptor URL, the Relying Party Agent MUST then issue an  
> HTTP GET request to the Yadis URL.

Fixing this in 8.1 may create an endless loop, since 8.1 is  
referenced from 8.2. So that portion in 8.2 would probably need to be  
revised as well.


Johnny

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

Re: Review of Yadis section in XRI Resolution 2.0 WD11

[Johnny Bufu]

On 31-May-07, at 5:34 PM, Recordon, David wrote:
> I'd recommend adding a section which pulls together the HEAD and GET
> methods and describes how'd they be used in conjunction.

In the interest of keeping it light and simple to process, I believe  
it would be enough to make this explicit just before 8.1 by saying  
that any of the two protocols MAY be attempted by an RP (plus fixing  
the fallback from HEAD to GET).

> Also explicitly pointing out that a URL hosting a XRDS document  
> only is
> required to implement one or more of the discovery mechanisms

Not "one or more"; GET is REQUIRED, HEAD is OPTIONAL in Yadis. This  
too can be specified inline in sections 8.1 / 8.2.

> whereas a service requesting XRDS documents must implement all of  
> the different
> methods.

An RP may choose to only do GET and not care about the more efficient  
(but optional on the server side) HEAD.


Johnny

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

Re: Specifying identifier recycling

[Johnny Bufu]

On 2-Jun-07, at 5:14 PM, Recordon, David wrote:
> I'd like to see this written as an
> extension so that if the first approach doesn't work, the Auth spec
> itself doesn't have to be "reverted.  Rather we can finish 2.0 and try
> implementing different approaches before deciding on the final way to
> solve this problem.

I thought we had agreed at IIW (for good reason) to address this in  
2.0. Other than the actual solution not being 100% clear, has  
anything changed?

Arguments for not putting it into an extension:
- users of provider's X who employs 'identifier recycling extension'  
would not be able to log into RP Y who doesn't understand the extension
- it's likely that whatever solution we come up with affects the  
discovery / verification processes, in which case it couldn't be  
pushed to an extension (we're trying to patch something about the  
_identifier_ itself, which is the center of each openid transaction).


Also, I believe the fragment approach can actually work, as detailed  
here:

http://openid.net/pipermail/specs/2007-May/001767.html

I haven't seen any replies to this, so would appreciate if others  
would go through the proposed changes and see if they all makes sense  
of I've overlooked something.


Thanks,
Johnny

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

Re: Specifying identifier recycling

[Johnny Bufu]

On 3-Jun-07, at 1:46 AM, Recordon, David wrote:

> I thought at IIW we agreed that if we could come to quick consensus  
> on a
> way to resolve the problem it would be a part of 2.0, otherwise it  
> would
> not...

Agreed, nobody wants to delay 2.0 indefinitely if we can't agree on  
how to solve this issue. But the issue was deemed important enough to  
be one of the only two on the 2.0 agenda.

> As concerns with the fragment proposal have been raised, which had the
> most agreement at IIW, it seems we no longer have consensus.

I haven't seen many actually; checking this thread for what can count  
as concerns reveals only:
a) Josh's initial email
b) Johannes' +1 to not adopting a solution that doesn't actually work
c) David acknowledging the concerns

This doesn't seem to me to carry enough weight to veto the fragment  
proposal, especially when a) has been / can still be addressed, and  
the fragment proposal made sense to a dozen people at that meeting.

> As seen in
> this thread, there are a wide variety of opinions as to how to resolve
> this concern.  I thus think merely picking one for the sake of putting
> something into 2.0 would be misguided.

True, there have been a few (I definitely wouldn't call it a wide  
variety) possible solutions mentioned, but none very well defined,  
and none had the support of 10+ people like the fragment did.

I have argued that it will have to be core (whether 2.0 or 3.0). I  
guess we should ask ourselves then if we really want this addressed  
in 2.0, and if yes then try to make it work.


So I ask again - does anyone see any issues with the fragments being  
used like this:

http://openid.net/pipermail/specs/2007-May/001767.html  

If not, I have a hard time understanding where exactly the consensus  
was lost.


Johnny

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

Re: The "WordPress" User Problem (WAS: RE: Specifying identifier recycling)

[Johnny Bufu]

On 5-Jun-07, at 8:00 AM, Recordon, David wrote:

> I think the largest concern I have with fragments, or really any
> pair-wise shared secret which can't be renegotiated, is that while it
> solves issues for the large service providers it actually inhibits
> OpenID within the grassroots community.

This concern is definitely something new; I haven't seen it expressed  
before.

> Imagine if I install WordPress (or insert other app here) on
> https://davidrecordon.com and check the "Use fragments to protect my
> OpenID" box.  A few months later I decide to remove WordPress, or an
> upgrade blows away my OpenID extension data, or I'm using an extension
> which stores the fragments in /tmp/ and they get blown away.  I now no
> longer have access to my accounts on all the relying parties I've
> visited.  Now what do I do?

What do you do today, if you forget your slashdot password and  
slashdot didn't implement account recovery? Most (if not all) RPs  
today do implement account recovery - they don't want to loose users,  
and they know users make mistakes and forget passwords.

> We can't count on each RP implementing an account recovery mechanism;
> remember OpenID outsources account management so you can focus on
> building you application.  I can't call up my service provider and ask
> them to fix it, since well I was using my own provider.

You should call up your OP then.

> I could try to
> call up my webhost and see if they can restore from a backup, but I'd
> guess by the time I realize what that check box in my WordPress
> extension settings did there may not even be backups anymore.  In the
> end, I'd be extremely frustrated that OpenID didn't work for me   
> and I'd
> write a really obnoxious blog post about how much OpenID sucks.
>
> So while we solve one aspect of the recycling problem, we end up
> creating a larger problem from the opposite side of the equation.  I'm
> certainly not arguing that we shouldn't solve this problem, nor that
> participation from large providers isn't vital, but would hate to  
> see us
> create a problem for all of the people out there that have really  
> helped
> gain OpenID traction.
>
> I don't want to say that I have the answers here, since I don't  
> think I
> do.  I do however see the following possible solutions:
>
> 1) The core specification only talks about fragments in relation to
> Relying Parties, to the extent that they should be stripped from  
> display
> though used as a unique key.  We do however need to address how a RP
> should handle display and account management differences when a  
> fragment
> changes.  I'm guessing it is unreasonable to expect every instance of
> https://davidrecordon.com to be replaced with
> https://davidrecordon.com/#231hwqai21jb when the fragment changes (not
> to mention that the fragment *must* remain private between the OP  
> and RP
> to be effective).  An extension is then written describing fragment
> usage from the OP perspective with huge warnings about how it should
> only be used by large service providers who know what they're doing.

I believe it could work with REQUIREments in the core for RPs  
(discovery, verification), and OPTIONAL / extension for the OPs.  
Though the gained simplicity I think would be minimal. But if the  
other advantage is that OPs don't carelessly implement this feature  
without knowing what they are doing, then it may be better overall.

Totally agree with the warnings / raising awareness that identifier  
recycling is an advanced feature. I believe this is part of a more  
general problem: by being decentralized, OpenID gives power to  
everyone (anyone can be an OP); while being an RP is / should be  
simple, doing the OP job right is not.

> 2) We use a centralized "canonical id" approach like i-numbers.
> Basically somebody issues unique and never reassigned ids.
>
> 3) We use a distributed "canonical id" approach.  Providers issue an
> ugly non-reassignable URL which points at the pretty one and vice- 
> versa.
> Thus https://davidrecordon.com says its canonical is
> https://12jbd9210.pip.verisignlabs.com which in turn says it is
> https://davidrecordon.com.  We could even kill two birds with one  
> stone
> and use "" to do this and setup an easy way to create
> identifier equality.

> I think my preference is #3, though I'm sure it has its own issues.

Do you have a more detailed proposal on how this would work? I do see  
a couple important / possibly show-stopper issues here, but I haven't  
really explored this direction for a solution. If you have, I would  
definitely be interested to learn more.

However, I still believe #1 is our best bet, if we can focus our  
efforts to make it work in such a way to address your grassroots  
adoption concerns. #1 did have (and still has, I hope) the support of  
a good many people, and has a concrete and detailed proposal. If we  
agree that _some_ changes to the core are required, then #1 has also  
the time advantage.


> 4) W

Re: Generalized solution to OpenID recycling (was RE: The "WordPress" User Problem)

[Johnny Bufu]

Hi Drummond,

On 5-Jun-07, at 9:44 AM, =drummond.reed wrote:

> I see no reason we can't add the rules for
> reassignable-URL-to-persistent-URL mapping as well, since it's  
> simply a
> matter of the RP confirming that the persistent identifier is also
> authoritative for the XRDS.
>
> If we approached it this way, all the OpenID Authentication 2.0  
> spec would
> need to do is specify the use of Canonical ID verification as part  
> of the
> OpenID discovery process, and then everyone -- users, OPs, and RPs,  
> would be
> able to use any
> reassignable-OpenID-identifier-to-persistent-OpenID-identifier mapping
> process that worked best for them.

Not knowing how you plan to have the canonical ID verification for  
URLs (really looking forward to reading tomorrow's draft), I'm not  
sure it's a simpler approach or even a generalization of the fragment  
proposal.

Yes, it would be simpler to specify in the OpenID spec, but it would  
include a pointer to a section of the XRI spec, which scares so many  
people away.

 From your comments I understand that the persistent identifier has  
to be discoverable; in the fragment approach, the fragment itself  
(which is the actual persistent part) is stripped out at  discovery  
time, and only comes into play at the auth response / verification  
stages (hence not sure the generalization applies).

Keying your identity on a new / different URL also brings in the  
management effort required to maintain that second, persistent URL  
(and making sure it stays persistent). If that is an absolute URL,  
the cost is considerably higher than just keeping track of your  
persistent fragment. (In this respect the fragment approach is simpler.)


Johnny

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

Re: Auth 2.0 Extensions: Namespace Prefixes

[Johnny Bufu]

On 5-Jun-07, at 8:53 AM, Granqvist, Hans wrote:

> But it seems superflous: Since you cannot depend on args to
> be ordered[1], you'll still need to iterate and match prefix
> to values.
Martin's proposal seems like a minor improvement to me - iterating  
thorough openid.ns.* or splitting the value of openid.extensions and  
then iterating through the result seems roughly equivalent.

Our implementation builds a map of extension aliases to namespaces  
when a message is received and after that, at any point during the  
life cycle of that message, extensions queries are  simple and quick  
map lookups.

So I'd rather not add the openid.extension field.

Johnny

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

Re: The "WordPress" User Problem (WAS: RE: Specifying identifier recycling)

[Johnny Bufu]

On 5-Jun-07, at 11:12 AM, Josh Hoyt wrote:

> On 6/5/07, Recordon, David <[EMAIL PROTECTED]> wrote:
>> Imagine if I install WordPress (or insert other app here) on
>> https://davidrecordon.com and check the "Use fragments to protect my
>> OpenID" box.  A few months later I decide to remove WordPress, or an
>> upgrade blows away my OpenID extension data, or I'm using an  
>> extension
>> which stores the fragments in /tmp/ and they get blown away.  I  
>> now no
>> longer have access to my accounts on all the relying parties I've
>> visited.  Now what do I do?
>
> The fragment is not secret. It is not "protecting" your OpenID. You
> should be able to get the fragment from any relying party that you
> visited.

I believe David's point is that you cannot retrieve the fragment from  
the RP if you have lost it and are no longer able to log into any  
RPs. (Unless there's an account recovery mechanism either on the RP  
or the OP.) The RPs know it, but are not supposed to display /  
disclose it.

> You might choose to use a fragment if you have acquired a
> recycled identifier, but you can choose the fragment. It protects
> *nothing* if you control the base identifier (to the point that you
> can choose an OpenID provider).

Agreed - if you loose control over the URL, you can no longer use  
your old online identity.

However, the issue / feature this does address is "protect your RP  
accounts if you loose your identity". (The new owner of  
davidrecordon.com would not be able to sign into the old  
davidrecordon.com's digg account.)


Johnny

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

Re: The "WordPress" User Problem (WAS: RE: Specifying identifier recycling)

[Johnny Bufu]

On 5-Jun-07, at 11:58 AM, Josh Hoyt wrote:
> The relying parties SHOULD make the fragment available to software
> agents, at least, so that it's possible to compare identifiers across
> sites. If the fragment is never available, then there is confusion
> about which user of an identifier is responsible for content that has
> been posted. One use case where software agents having access to the
> fragment is particularly important is if the identifier is used for
> access control, and the access control list is retrieved from off-site
> (e.g. from a social networking site).
>
> The implementation that seems most sane is for places that display the
> identifier for human reading look like:
>
> http://josh.example.com/#this-is-intended-for-machine- 
> consumption"
>  >http://josh.example.com/
>
> so that the software agent would see the fragment, but the user
> wouldn't have to.

On 5-Jun-07, at 2:55 PM, Recordon, David wrote:

> I thought the fragment was to be secret so that for the case of  
> using a
> personal domain you don't have to own joshhoyt.com forever.  Rather as
> long as your fragments are secret, someone else can buy  
> joshhoyt.com and
> not be you.  If this is no longer a requirement then it certainly
> changes the game, though also doesn't solve one of the other  
> aspects of
> identifier recycling.

I thought so too, but I believe Josh is right - the "lost domain"  
cell with an X in it (for URL + public fragment) supports Josh's  
statement:
http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling

So if we're not dealing with this use case, it becomes actually  
simpler to address just the identifier recycling for big OPs, where  
loosing the domain is not an issue.


Johnny

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

Re: Questions about IIW Identifier Recycling Table

[Johnny Bufu]

Hi David,

The idea was to list as columns the things potentially affected by  
this change and important enough that we cared. In the end we chose  
'URL + public fragment' as the one with the most check marks.

See below my comments; maybe others can correct / fill in the gaps.

On 5-Jun-07, at 1:36 PM, David Fuelling wrote:

> I wasn't at IIW, so please bear with me.
>
> In reference to the wiki at
> http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling, can  
> somebody
> clarify what some of the terminology means?  Specific questions are  
> below.
>
> 1.) For URL+Fragment, what is the distinction between "private" and
> "public"?
>
> 2.) Ditto For URL+Token (I assume this means a public vs. private  
> token?)

Public: the RP presents the full identifier (fragment included) to  
third parties.

Private: the reverse of the above. Not sure if this also covered the  
case (mentioned the day before the meeting) of the OP generating  
custom fragments for each RP.

> 3.) What does "DE" mean in the "Does not require change to DE"?

Delegation. Corrected the wiki.

> 4.) In the "Stolen OP account" header, it appears that all 4 of the  
> proposed
> methods have problems.  However do we really want an identifier to be
> recycled if an account is stolen ( i.e., what if an account is only  
> stolen
> for a brief period, but then recovered?)

Rather, neither of the for proposed methods help you if your OP  
account is stolen, so this column doesn't make a difference.


> 4.) What is "Active Recycling"?

Not 100% here, but I believe the user / OP can choose when to recycle  
an identifier.


> 5.) In the "New DB Field" header, doesn't an OP/RP need a new DB  
> field in
> the fragment scheme, in order to distinguish between the id and the  
> current
> fragment?  Or does the OP/RP simply store the whole URL (fragment  
> included)
> and parse as necessary?

Corrected this one to "One identifier / New DB field" as it shows in  
my picture.

The RP can dynamically strip the fragment when it needs to display  
the identifier, and keep it in full (including the fragment) for the  
rest of the cases.

> 6a.) What is "MO" in "MO Strip Fragment"?
>
> 6b.) What does the "MO Strip Fragment" header mean in general?

"No strip fragment" == "there is no extra work required for stripping  
the fragment". This is kind of a mirror of the previous column ("one  
identifier"), but dynamically stripping the fragment was considered  
better than requiring a new DB field for the tokens (so this mirrored  
column pair was regarded slightly in favor of fragments vs tokens).


The "lost domain" shows as "lost domain when owning OP" in my  
picture. This was considered less important (and smaller in size on  
the whiteboard). I also don't remember why private fragments/tokens  
don't help here, or why the public token does.


Johnny

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

Re: No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table)

[Johnny Bufu]

On 8-Jun-07, at 10:02 AM, Recordon, David wrote:

> I'm confused as to why a RP having to not create a new DB field is a
> requirement when looking to solve this problem.  RP's implementations
> already need to change to upgrade from 1.1 to 2.0 and this has never
> been a requirement in the past.  It certainly is nice that storage
> changes wouldn't be needed, but I don't see it as something that  
> should
> be a requirement.

My feeling was that, all other things being equal, some bits of code  
(stripping the fragment for display purposes) which ideally would go  
into the library, were preferred to requiring a schema change (to  
store the separate token) for the RPs. Not a requirement, but a  
strong preference.


Johnny

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

Re: The CanonicalID Approach

[Johnny Bufu]

Hi David,

On 7-Jun-07, at 6:31 PM, Recordon, David wrote:

> You could also, don't shudder too hard Dick :), use an i-number
> as your persistent identifier via this method though on the flip-side
> could also use a fragment if that is the approach someone would  
> like to
> take.
>
> The nice thing is that this method is extremely flexible in terms of
> what you use as your persistent identifier in different cases.

The question (that we will need to specify or have a clear pointer  
to) is how the canonical ID verification is done. (BTW: Was this  
section updated on Wed in the XRI draft?)

Your HTTP URL canonical ID example is straight-forward and simple. Do  
you have an example of how it would work with fragments, say:

http://openid.aol.com/daveman692 - reassignable
http://openid.aol.com/daveman692#1234 - persistent


Thanks,
Johnny


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

Re: The CanonicalID Approach

[Johnny Bufu]

On 8-Jun-07, at 2:26 PM, Drummond Reed wrote:
> See my next message about this. It works identically to David's  
> examples
> (just substitute these as reassignable and persistent identifiers)  
> except it
> has the advantage that it does not require an extra round-trip for
> discovery/verification of the persistent identifier (the Canonical ID)
> because the client can verify from the identifiers themselves that the
> provider of the reassignable identifier (the first one) is  
> authoritative for
> the persistent identifier (the second one).

In essence, it would then be the same flow I detailed last week [1],  
would you agree?

Specifically, the "canonical id verification" above is:

> c) Verification of discovered information against auth response  
> fields:
>   strip_fragment(openid.claimed_id) == discovered claimed id


So the fragment approach would match Josh's request for no extra  
discovery [2]. Allowing for more general canonical IDs would require  
a more complex verification process.


Johnny

[1] http://openid.net/pipermail/specs/2007-May/001767.html
[2] http://openid.net/pipermail/specs/2007-June/001851.html

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

Re: The CanonicalID Approach

[Johnny Bufu]

On 8-Jun-07, at 3:04 PM, Drummond Reed wrote:

> http://openid.aol.com/daveman692 - reassignable
> http://openid.aol.com/daveman692#1234 - persistent
>
> If an XRDS for the reassignable identifier asserts the persistent  
> identifier
> as a Canonical ID, a second round trip is not required because the  
> client
> can verify that http://openid.aol.com/ is authoritative for both  
> daveman692
> and daveman692#1234.

Because in the case of URLs delegation is decoupled from the  
identifiers, I don't think that verifying only the authority part  
will suffice.

I could have the XRDS at:

http://openid.aol.com/johnny692

assert the cannonical ID:

http://openid.aol.com/daveman692#1234

.. but have http://openid.aol.com/johnny692 delegate to my own OP  
running in my basement, which is configured to issue assertions with  
the above canonical id. Checking only the authority section would  
render such assertions valid.

Unless I'm missing something, I believe we should mandate a stricter  
verification, on the full URL without the fragment. (Whoever controls  
the URL without the fragment, also controls the URL with any fragments.)


Johnny

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

Re: Writeup of XRDS Canonical ID verification for URLs and XRIs

[Johnny Bufu]

Drummond,

On 13-Jun-07, at 7:04 PM, =drummond.reed wrote:

> With the Yadis specification now included in section 4 of XRI  
> Resolution
> Working Draft 11 (see
> http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris  
> for a copy
> of the text of this section -- thanks to David, Johnny, and Rowan for
> feedback on the first draft)

A bit more feedback on the Yadis section, hope you don't mind. The  
overview section (4.1) still says:

> A service hosting an XRDS document discoverable through an HTTP(S)  
> URI is only required to support one option

Which is not equivalent with the Yadis spec, 6.2.4. Initiation:

> This request MUST be either a GET or a HEAD request.

Since the client has the option to do only GET (and the server is  
required to respond), the server doesn't have a choice to support  
only HEAD. GET is required , HEAD is optional (because of the  
required fallback on the client side).


> extending Canonical ID verification to cover
> any combination of URLs and XRIs is quite straightforward.
>
> The formal proposal is now fully written up on the XRI TC wiki. The  
> first
> link below is to the full page; the second takes you directly to  
> the example
> section.
>
>   http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification

Looks ok to me. For the OpenID spec, it seems we have two options now:

1) Use canonical IDs for URLs, and reference section 11 from the XRI  
spec for the verification part
pros:
addresses recycling issue
brings in a (possibly) persistent identifier, addressing issue 
B)  
here [1]
cons:
possible issue with defining the canonical ID (or an alternate  
path) for HTML discovery
need to adjust how the claimed id is handled with Yadis 
discovery
more complex than 2) (more canonical id verification paths)

2) Adopt the fragment proposal and specify it inline [2]
pros:
addresses recycling issue
simpler than 1)
cons:
does not address issue B here [1]


Johnny


[1] http://openid.net/pipermail/specs/2007-June/001847.html
[2] http://openid.net/pipermail/specs/2007-May/001767.html

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

Re: OpenID Provider Authentication Policy Extension

[Johnny Bufu]

David,

On 22-Jun-07, at 9:46 AM, Recordon, David wrote:
> So please, check it out and let me know what you think...especially
> around the questions in the Editorial Comments section at the end.

Here are the issues that came up while I implemented PAPE in  
openid4java:


5.1 Request Parameters

- Is preferred_auth_policies REQUIRED? Assume yes, but not clearly  
spelled out.

- "the OP MUST authenticate the End User for this request."

What if the OP / user don't want to re-authenticate, and have reasons  
to continue their session with the previous / old auth? (For example  
user changed his mind at the OP about buying the book from amazon,  
and declines the OP's request to re-authenticate).

- "The OP should realize that not adhering to the request for re- 
authentication..." implies there is an alternative to the above  
(other than breaking the protocol). Maybe the MUST above should be a  
SHOULD?

- (max_)auth_age is defined as "numeric". Is there value for allowing  
floating-point numbers here? Would be simpler to be an integer.


5.2 Response Parameters

- auth_age: What should the value be if the OP did not actively  
authenticate the user for the current session? Suggesting "unknown"  
as a special value for this.

- auth_age: Since the message may spend a (not-insignificant) time  
after it's created (by the library)
before it's put on the wire
on the wire
while it's being processed by the RP
a timestamp value may be better suited here (rename it to auth_time  
maybe?). This way the RP will be able to determine the auth_age at  
any time (e.g. when it actually needs to perform the sensitive  
operation). Could use the formating used for nonces (from RFC3339).

- nist_auth_level: "Numeric value" - probably was meant as integer  
value.


Thanks,
Johnny

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

Re: OpenID Attribute Exchange Protocol questions

[Johnny Bufu]

Hi James!

On 4-Jul-07, at 9:05 PM, James Henstridge wrote:
> 1. I noticed a few typos in the examples.  In section 5.1, it gives an
> example of a fetch_request request reading:
>
> openid.ns.ax=http://openid.net/srv/ax/1.0
> openid.ns.ax=fetch_request
> ...

This would be a copy / paste error on my part; thanks for finding it!  
It's fixed now.

> 2. The spec seems to omit details of how messages should be sent to
> openid.ax.update_url.  In particular:

Draft 5 is a bit old; there was also a draft 6 that never made it to  
the index page on openid.net.

The latest revision in svn [1]  should be tagged as draft-7 any time  
now. Please have a look at it and see if there are still issues with  
the update mechanism (or anything else for that matter).


Thanks for the feedback!
Johnny


[1] http://openid.net/svn/specifications/attribute_exchange/1.0/trunk/ 
openid-attribute-exchange.html
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID Attribute Exchange Protocol questions

[Johnny Bufu]

On 6-Jul-07, at 12:37 AM, James Henstridge wrote:
> My question about the transaction ID in the update URL still stands:
> won't a positive assertion response include openid.identifier and
> openid.claimed_id, which should be enough for the RP to match up the
> response?  Or do you expect the OP to not record the claimed
> identifier from the original authentication request?

There is a use case for OpenID (though not very well defined) where  
the OP could send a positive assertion without identity / claimed_id  
fields (e.g. if the RP only requests the zipcode). For something like  
this, the RP may (note the lowercase may in the AX spec as well) add  
whatever identifying information it needs (not necessarily for a user  
id / account).

> I think my question about what association handle to use for the
> unsolicited response is adequately covered by the rules in section
> 11.4 of the OpenID Authentication spec: the OP could choose to use the
> association from the original authentication request (if it is still
> valid), or create a new private association handle.

Yes, the update uses the signature mechanism in the underlying OpenID  
message.

> In either case, it should be ready to answer a check_authentication  
> request.

Not entirely; the OP MUST NOT honor check_authentication requests for  
shared associations (this would allow a type of attack).


> 1. The RP requests my phone and fax numbers in an OpenID  
> authentication request:
>openid.ns.ax=http://openid.net/srv/ax/1.0
>openid.ax.mode=fetch_request
>openid.ax.type.phone=http://example.com/phone
>openid.ax.type.fax=http://example.com/fax
> [...]
> 3. At some later date, my OP sends an unsolicitated authentication
> response containing the following data:
>openid.ns.ax=http://openid.net/srv/ax/1.0
>openid.ax.mode=fetch_response
>openid.ax.type.phone=http://example.com/phone
>openid.ax.value.phone=555-2345
>openid.ax.update_url=http://relying-party/...
>
> How should the RP handle this update?  According to the draft spec, I
> can think of two possibilities based on how "updated data" is
> interpreted?
> 1. the user has changed their phone number
> 2. the user has changed their phone number and removed their fax  
> number.

I don't think it's implied anywhere (or a good design) to keep state  
between the original request and subsequent updates. So the RP cannot  
infer the 'removed' statement just because an update did not contain  
an attribute that was part of the original exchange.

The update message is a fetch response, so I think it should be  
interpreted as such by the RP: "the user has a new phone number".  
Then the RP can decide what it wants to do with the new value, as if  
it had requested the same attributes again.

To indicate that the user has deleted an attribute, the count=0  
mechanism can be used:

> An "openid.ax.count." with a value of "0" together with its  
> corresponding "openid.ax.type." field MAY be included to  
> explicitly state that no values are provided for an attribute.


Johnny

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

Re: OpenID Attribute Exchange Protocol questions

[Johnny Bufu]

On 6-Jul-07, at 3:54 AM, James Henstridge wrote:
>> Not entirely; the OP MUST NOT honor check_authentication requests for
>> shared associations (this would allow a type of attack).
>
> Okay.  In that case it sounds like it would be best practice to
> generate a private association handle for each unsolicited response
> since there is no guarantee that the RP has kept hold of its
> association handle, so may not be able to verify the update if a
> pre-existing handle is used.

The OPs knows the expiration time for each handle, so if they link  
them with the update URLs they can determine their validity.

But most of the time the updates will probably happen at much longer  
intervals than association expiry time, so using private association  
would be required.

> Would that be appropriate to include in the spec or some best
> practices document?

I see this as a pure OpenID (core) issue and don't feel the need to  
touch it in the AX spec.

>> I don't think it's implied anywhere (or a good design) to keep state
>> between the original request and subsequent updates. So the RP cannot
>> infer the 'removed' statement just because an update did not contain
>> an attribute that was part of the original exchange.
>>
>> The update message is a fetch response, so I think it should be
>> interpreted as such by the RP: "the user has a new phone number".
>> Then the RP can decide what it wants to do with the new value, as if
>> it had requested the same attributes again.
>
> Thank you for the clarification.  It seems that an OP will get the
> most consistent results if it always sends all attributes in an update
> then, so it doesn't need to track whether intermediate updates failed
> (or track exactly which attributes were changed).

Sending all of the originally requested attributes would also require  
the OP to keep an "original request" data structure for each Fetch  
Request with an update_url in it, with the possibility of  
conflicting / overlapping requests.

A cleaner way would be to attach a list of update URLs to each  
attribute in the user's profile, and when that attribute's value  
changes to post an update to the RP (after prompting the user etc.).

>> To indicate that the user has deleted an attribute, the count=0
>> mechanism can be used:
>>
>> > An "openid.ax.count." with a value of "0" together with its
>> > corresponding "openid.ax.type." field MAY be included to
>> > explicitly state that no values are provided for an attribute.
>
> It might be worth demonstrating this in the example from section 5.2
> then.  Currently it reads:
>openid.ax.type.gender=http://example.com/schema/gender
>...
>openid.ax.value.gender=
>
> If this is a case where the user has not given their gender it should
> perhaps use "openid.ax.count.gender=0" instead.

You are right - thanks for catching this one as well! Previous drafts  
required that empty values are sent if the user did not send a  
meaningful value (which led to confusions and were clarified with the  
count param).


Thanks,
Johnny

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

Re: OpenID Attribute Exchange Protocol questions

[Johnny Bufu]

On 10-Jul-07, at 8:43 AM, James Henstridge wrote:

> On 10/07/07, Dick Hardt <[EMAIL PROTECTED]> wrote:
>> > Given that there doesn't seem to be any way to recover from this
>> > situation, it seems like private associations are the only sane  
>> option
>> > for unsolicited responses.
>>
>> An update message would require direct verification and not use an
>> association. Associations are set by the RP, and in this case, the OP
>> is initiating the conversation. I might be missing something, but I
>> don't see how you can reliably use an association.
>
> That was the conclusion that I came to.
>
> I was replying to Johnny's statement that the OP knows the expiry time
> of the association handles it stores so could use a previously
> negotiated handle in the unsolicited response.
>
> I think it would be good to include a statement to this effect in the
> specification so that implementers don't have to work this out for
> themselves (and maybe get it wrong).


Looks like it's already in the spec, in section 10,  Responding to  
Authentication Requests:

> If no association handle is specified, the OP SHOULD create a  
> private association for signing the response. The OP MUST store  
> this association and MUST respond to later requests to check the  
> signature of the response via Direct Verification.

http://openid.net/specs/openid- 
authentication-2_0-11.html#responding_to_authentication


Johnny

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

Re: OpenID Provider Authentication Policy Extension

[Johnny Bufu]

David,

On 22-Jun-07, at 9:46 AM, Recordon, David wrote:

> So please, check it out and let me know what you think...especially
> around the questions in the Editorial Comments section at the end.
>
> http://openid.net/specs/openid-provider-authentication-policy- 
> extension-
> 1_0-01.html

Hope you're still welcoming feedback on this..

While trying to explain what PAPE is/does, I noticed that the term  
'authentication policy' is not explicitly defined in the spec (and  
how a policy differentiates from a specific authentication  
mechanism). A clear definition could help eliminate confusion between  
the two.


Johnny

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

Re: OpenID Provider Authentication Policy Extension

[Johnny Bufu]

On 21-Jul-07, at 4:55 PM, Recordon, David wrote:
> 5.1
> 1) Clarified.
>
> 2 & 3) Changed the MUST to a SHOULD, since the intent was never to
> restrict what a user could do.
>
> 4) Changed to "Integer"
>
> 2) I'm fine with time coming back instead of number of seconds.
>
> 3) Changed to integer.

Great, thanks. Were these checked-in? I don't see them in SVN yet.

> 5.2
> 1) What is the use-case for this?  As the parameter always  
> describes the
> policies returned in pape_auth_policies, the Provider should always  
> know
> how long ago the user authenticated within the session.

Depending on how 'active authentication' is defined, there may be no  
such authentication performed at all. If there is no 'active  
authentication', there can't be an age for it either.

Specifically, Sxipper never prompts users for their password (that's  
what I think 'active' means). Maybe also clarify then 'active  
authentication'?

Or, if auth_age/time is intended to describe only the requested /  
performed authentication policies, remove the 'active' word from the  
description of the field, and define a new 'active authentication'  
policy (which can be requested separately), and tie the auth_age/time  
in the response to it.


Thanks,
Johnny

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

Re: Differentiating between User Identifier and OP Identifier

[Johnny Bufu]

Hi Eran,

On 27-Jul-07, at 8:33 PM, Eran Hammer-Lahav wrote:
> Section 2 describe the User-Supplied Identifier, and section 3  
> bullet 2
> provided the workflow, allowing users to provide a User Identity or  
> an OP
> Endpoint ID. Section 7.3.1 provides a little more information but  
> not much.
> The document is not very clear about the difference and how to  
> decide what
> ID the user supplied. It is critical as the end of section 7.3.1  
> requires
> special value of the id fields to be used with an OP Endpoint.

The service type determines this for XRDS based discovery.

For HTML discovery:

"7.3.3.  HTML-Based Discovery
[...] HTML-Based discovery is only usable for discovery of Claimed  
Identifiers. OP Identifiers must be XRIs or URLs that support XRDS  
discovery."


> If the ID discovery leads to an XRDS document, I am guessing that  
> if that
> document contains an OP Identifier element, it might mean that this  
> is a
> server Id, but what if it also contains a claimed Id element? Is  
> that not
> allowed?

"7.3.2.2.  Extracting Authentication Data

Once the Relying Party has obtained an XRDS document, it MUST first  
search the document (following the rules described in  
[XRI_Resolution_2.0]) for an OP Identifier Element. If none is found,  
the RP will search for a Claimed Identifier Element."

> And in that case, is the Canonical Id ignored?

If an OP Identifier element was found, there is no claimed identifier  
and yes - the canonical id is ignored. The claimed_id field is set to  
the special value "http://specs.openid.net/auth/2.0/identifier_select";

> But this theory only works for XRDS discovery.

Correct.

> What about HTML discovery?

See above.

> Also, is there a difference in the handling of an XRDS discovery  
> depending on how it was
> attained (XRI or Yadis)?

Yes, in the way the claimed identifier is determined (canonical id  
for XRIs vs normalized URL). See section 2.

BTW: Yadis was merged into the XRI resolution spec, where it occupies  
one section that fits into one browser window page and is (in my  
opinion) much easier to read and implement:
http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris

(We have proof-read it a few weeks ago to make sure it's 100%  
equivalent to the Yadis spec.)


> Also, should I be using / referencing a newer version of the 2.0  
> draft?

Draft 11 is the latest published one.

The notable changes in SVN since draft 11 are:
- realm validation
- identifier recycling
http://openid.net/svn/listing.php?repname=specifications&path=% 
2Fauthentication


Hope this helps,
Johnny

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

Re: Using XRI Proxy Resolvers in OpenID discovery

[Johnny Bufu]

On 28-Jul-07, at 6:14 PM, Eran Hammer-Lahav wrote:

> The spec requires HTML discovery but not the other
> two, but users are expected to try their XRI identities not knowing  
> what the
> RP will support.

This is not correct. For URL identifiers Yadis and HTML discovery are  
both required for RPs:

"7.3 Discovery
[...]
2. If it is a URL, the Yadis protocol [Yadis] SHALL be first  
attempted. If it succeeds, the result is again an XRDS document.
3.If the Yadis protocol fails and no valid XRDS document is  
retrieved, or no Service Elements are found in the XRDS document, the  
URL is retrieved and HTML-Based discovery SHALL be attempted."


On the OP side:
- one of the [Yadis | HTML] discovery is required for OpenID 2.0.
- HTML discovery is required for compatibility with OpenID 1.1 RPs.


Johnny

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

Re: Using XRI Proxy Resolvers in OpenID discovery

[Johnny Bufu]

On 30-Jul-07, at 12:08 PM, Eran Hammer-Lahav wrote:

> But that doesn't address my point about XRI support.

The referenced XRI Resolution document does.

The goal of discovery is to provide the RP with an OpenID service  
endpoint that is authoritative for an identifier. To this end, the  
OpenID spec says "[XRI_Resolution_2.0] will yield an XRDS document  
that contains the necessary information".

How a proxy resolver can be used is detailed in the XRI Resolution  
spec, but it can be as simple as retrieving an XRDS file from a URL /  
HXRI.


Johnny

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

Re: Differentiating between User Identifier and OP Identifier

[Johnny Bufu]

On 28-Jul-07, at 10:00 AM, Eran Hammer-Lahav wrote:
> Section 7.3.1:
>
> "If more than one set of the following information has been  
> discovered, the
> precedence rules defined in [XRI_Resolution_2.0] are to be applied."
>
> This somewhat confusing when combined with section 7.3.2.2:
>
> "Once the Relaying Party has obtained an XRDS document, is MUST  
> first search
> the document (following the rules described in  
> [XRI_Resolution_2.0]) for an
> OP Identifier Element."

It's the same thing, stated in two different places: 7.3 / 7.3.1 are  
an overview / introduction of the discovery process, while 7.3.2.2 is  
specific to the XRDS discovery.

> My confusion comes from the fact the spec is not clear about what  
> makes a
> valid XRDS document used for OpenID discovery.

Not sure 'valid' is the right term here. If the RP obtains an XRDS,  
it may or may not be able to extract an OP Identifier Element or a  
Claimed Identifier Element.

If it can't, the RP is required to fall back to HTML discovery.

> In this case, it sounds like
> an XRDS document MUST no include both an OP Endpoint element and a  
> Claimed
> Identifier element.

I don't see this implied anywhere. Do you have a specific pointer or  
a clear reasoning for this?

> If it has both, and the Claimed Identifier Service
> Element has a higher priority, what does that mean?

It's the other way around: the OP Identifier Element has higher  
priority, so the Claimed Identifier Element doesn't get used in such  
a case.

> Remove section 7.3.2.2 and move its content to the end of 7.3.2. It  
> makes a
> better introduction to the two possible elements and their  
> relationship.

It would then use terms that have not been defined / explained yet  
(OP Identifier Element / Claimed Identifier Element).

> Section 7.3.2.3 is confusing:
> 1. Does it only apply to XRI identifiers, not to XRDS documents  
> found during
> Yadis discovery?

Yes: "When the identifier is an XRI...".

> 2. It seems to only apply to Claimed Identifier Element - maybe it  
> should
> merge into section 7.3.2.1.2?

Yes, the canonical id is used only when there is a claimed identifier  
(an OP Identifier was not discovered).

Not sure moving it would be good - the previous subsections outline  
the flow of processing the discovered information. Inserting the  
XRI / canonical id special case in the middle of it would make it  
harder to read / understand I believe.

> 3. It would be helpful to explain or reference how the RP can  
> confirm the
> authorities listed in the 2nd paragraph. I read a couple of long  
> threads on
> this list regarding this, but did not see a resolution.

The XRI people are still working on it and the details should be  
available in the soon-to-be-published draft 12 of the XRI Resolution.  
Agree that a the XRI Resolution should be referenced from this  
paragraph.

> 4. The first line of the third paragraph is not needed.

True, the same MUST is in the second phrase of the first paragraph.

> 5. The section briefly explains the  tag, but not the
>  tag. A one line context of the  tag would  
> help.

> 6. Last line is confusing. Where would a  come from if  
> using a
> URL identifier? This entire section is under XRDS discovery. Does  
> it refer
> to the URL used in a Yadis discovery (I assume not)?

What made you think a canonical id is needed for URLs? It is not --  
for URLs the claimed identifier is determined as described in the  
normalization section.

> Section 7.3.2.4 says "...no longer used..." but it is not clean  
> where was it
> used before? The only spec I read prior this this one was the  
> OpenID 1.1
> which does not make use of XRDS documents.

True, however there are OpenID 1.1 deployments that use Yadis / XRDS.  
(The openid namespace was used in Yadis for the delegate element.)

> Move the first paragraph of section 7.3.3 to the end of section  
> 7.3.1. It
> will explain which discovery process is used for each of the possible
> identity types.

This is outlined just before that, in the discovery overview section  
- 7.3.


> Also, from "HTML-Based discovery MUST be supported by
> Relaying Parties" is sounds like XRDS discovery is not required.

How do you come to this conclusion?

> If this is true, it should be made much clearer and provide  
> guidelines of the proper
> reply to the user when the RP only supports HTML discovery.

It's false actually. Following the flow of discovery on the XRDS  
path, at 7.3 bullet 2 there is a SHALL  (which is the same as REQUIRED).

The statement above is in the HTML discovery section and applies only  
to HTML discovery. Not sure how / why you tend to apply or draw  
implications about the XRDS discovery from it.


Johnny

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

Re: Differentiating between User Identifier and OP Identifier

[Johnny Bufu]

On 30-Jul-07, at 8:48 PM, Eran Hammer-Lahav wrote:
>>> In this case, it sounds like an XRDS document MUST no include both
>>> an OP Endpoint element and a Claimed Identifier element.
>>
>> I don't see this implied anywhere. Do you have a specific pointer or
>> a clear reasoning for this?
>
> If an XRDS has both elements, the RP will try the server and if it  
> doesn't
> work for some reason (server down, etc.) it will move on to Yadis,  
> not to
> the next signon service (7.3.2.2: If none is found, the RP will  
> search for a
> Claimed Identifier Element).

But an OP Identifier Element _was_ found, so the RP should not even  
process Claimed Identifier Elements, if they exist for whatever reason.

> It doesn't say "if none is found or all server
> endpoints have been attempted and failed". Ok, so MUST is wrong in my
> statement. It should be: "an XRDS document SHOULD not include both  
> an OP
> Endpoint element and a Claimed Identifier element".

The OpenID spec is not authoritative for what XRDS documents can or  
cannot contain; it just says how to consume them for the purposes of  
OpenID authentication.

>> It's the other way around: the OP Identifier Element has higher
>> priority, so the Claimed Identifier Element doesn't get used in such
>> a case.
>
> In this example, the OP Identifier element has a lower XRDS  
> priority than
> the Claimed Identifier Element. It's about the intention of the  
> document
> author - this one says use sigon before server. The OpenID 2.0 spec  
> implies,
> only use the priority value between services of the same element type.

The Service type supersedes the priority attribute; priority is taken  
into account for services of the same type.

This is what the protocol states, and the document's author intention  
does not override them ;-)

>>> Section 7.3.2.3 is confusing:
>>> 1. Does it only apply to XRI identifiers, not to XRDS documents
>>> found during Yadis discovery?
>>
>> Yes: "When the identifier is an XRI...".
>
> Only because it goes on discussing XRDS documents. Does the last  
> line about
> URL implies using Yadis to get to an XRDS document (where one would  
> find a
> Canonical ID to ignore as instructed)?

Yadis is used to get XRDS documents for URLs - not sure what you're  
asking here.

The last sentence aims to answer the question "what if I get a  
canonical id in an XRDS discovered from a URL".


>>> 4. The first line of the third paragraph is not needed.
>>
>> True, the same MUST is in the second phrase of the first paragraph.
>
> Is this email enough to have an editor consider/make the change?

While not strictly needed, why is this particular reinforcement bad?


>>> 6. Last line is confusing. Where would a  come from if
>>> using a
>>> URL identifier? This entire section is under XRDS discovery. Does
>>> it refer
>>> to the URL used in a Yadis discovery (I assume not)?
>>
>> What made you think a canonical id is needed for URLs? It is not --
>> for URLs the claimed identifier is determined as described in the
>> normalization section.
>
> Exactly! So why is URL even mentioned here? See my point? :-)

Sorry, no. The URL case is mentioned to answer the valid question above.


>>> Also, from "HTML-Based discovery MUST be supported by
>>> Relaying Parties" is sounds like XRDS discovery is not required.
>>
>> How do you come to this conclusion?
>
> See comments in previous email on XRI proxies.

Those do not come to the same conclusion - while support for XRIs is  
left for each RP to decide, the same does not apply to the XRDS /  
Yadis discovery for URLs.


Johnny

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

Re: Using XRI Proxy Resolvers in OpenID discovery

[Johnny Bufu]

On 30-Jul-07, at 12:58 PM, Eran Hammer-Lahav wrote:

> It has been mentioned on this list that XRI might be optional in  
> OpenID 2.0.
> If you read the spec with that mindset you can find ways to prove it.

Yes, support for XRIs is left for each RP to decide (as is a number  
of other things).

> Your answer is that all three discoveries are a MUST and if that's  
> the case,
> there is little point in this thread.

I don't think I have stated something that would imply this.

> OpenID 1.1 allowed for a very dumb RP. I was able to implement the  
> entire
> spec from scratch in C++ in under a day. OpenID 2.0 took 10 days  
> and it's
> still not complete (missing authority validation). My suggestion  
> was to
> consider allowing RP's to avoid dealing with XRI and XRDS by  
> requiring HTML
> discovery support on the End User side,

Do you mean the OP side? (The end user is only required to have a  
browser.)

Yadis is required for RPs. (There are good reasons for the HTML ->  
Yadis "upgrade")

Making Yadis optional for RPs and HTML mandatory for OPs would break  
other things - like the OPs offering inconsistent discovery  
information to RPs, based on their preference for Yadis or HTML.


Johnny

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

Re: OpenID Provider Authentication Policy Extension

[Johnny Bufu]

Hi David,

> On 22-Jun-07, at 9:46 AM, Recordon, David wrote:
>> So please, check it out and let me know what you think...especially
>> around the questions in the Editorial Comments section at the end.
>
> Here are the issues that came up while I implemented PAPE in
> openid4java:
>
> [...]
>
> 5.2 Response Parameters
> [...]
> - auth_age: Since the message may spend a (not-insignificant) time
> after it's created (by the library)
>   before it's put on the wire
>   on the wire
>   while it's being processed by the RP
> a timestamp value may be better suited here (rename it to auth_time
> maybe?). This way the RP will be able to determine the auth_age at
> any time (e.g. when it actually needs to perform the sensitive
> operation). Could use the formating used for nonces (from RFC3339).

On 21-Jul-07, at 4:55 PM, Recordon, David wrote:
> 5.2
>
> 2) I'm fine with time coming back instead of number of seconds.


I wanted to bring openid4java up to the latest PAPE spec, and it  
seems the above was not checked in yet. Do you still have it on your  
todo list, or would it help if I sent you a proposed patch for it?


Thanks,
Johnny

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

Re: OpenID Provider Authentication Policy Extension

[Johnny Bufu]

David,

On 9-Aug-07, at 11:28 AM, Johnny Bufu wrote:
> On 21-Jul-07, at 4:55 PM, Recordon, David wrote:
>> 5.2
>>
>> 2) I'm fine with time coming back instead of number of seconds.
>
> I wanted to bring openid4java up to the latest PAPE spec, and it
> seems the above was not checked in yet. Do you still have it on your
> todo list, or would it help if I sent you a proposed patch for it?

Did you have a chance to have a look at this? Not sure if you're  
having second thoughts about it, or just slipped through your busy  
schedule.

Would be great if this change went in the PAPE spec sometime soon, so  
that it can be included in the next release of openid4java.


Thanks,
Johnny

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