Re: Backporting the 2.0 extension mechanism to 1.1

2008-08-11 Thread Johnny Bufu


On 11/08/08 12:49 AM, Martin Atkins wrote:
 I notice that, like sreg, the pape extension is supporting 1.1 by simply 
 hard-coding the pape prefix on its arguments.

Where/how? To my knowledge the opposite is true, per the last paragraph 
here:

http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-02.html#anchor3


Johnny

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


Re: Problems with OpenID and TAG httpRange-14

2008-03-20 Thread Johnny Bufu

On 20-Mar-08, at 4:40 AM, Noah Slater wrote:

 On Wed, Mar 19, 2008 at 08:59:24PM -0700, Johnny Bufu wrote:
 Yes, it is.
 [snip]
 The new claimed_id URL is the address of the discovered information
 (which is of interest to the RPs in this case).

 No, it really isn't.

 Your argument, as far as I understand it, is that HTTP redirects  
 imply the
 original URI has an identity relationship final URI. You are using  
 the example
 of the address bar in a browser to illustrate this, i.e. I type in  
 X and
 eventually it changes to Y, so X must equal Y.

Not at all! My argument is, rather:

X and Y are two different things, with two different meanings. If  
the browsers are allowed to use Y as they deem appropriate, there's  
no reason why OpenID discovery can't do the same.

Where the semantic defined by OpenID for X and Y is:
User-supplied ID: X
Claimed ID: Y

And by the browsers:
URL typed in by the user: X
address of the displayed response: Y

 This is of course false, as explicitly stated in the HTTP  
 specification:

It would be, if OpenID said that User-supplied ID must take the value  
of Y.  Instead, it defines a new entity (Claimed ID) and assigns the  
value of Y to it.

I'm arguing that this assignment is not under the scope of the HTTP  
spec, and haven't yet seen an explanation of why it would be. This  
part has to be explained before quoting from the HTTP spec.

I also see no flaw in the above parallel with the browsers. Your  
argument seems to give browsers different privileges than to OpenID  
discovery, and I fail to see a good reason for this.


Johnny

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


Re: Problems with OpenID and TAG httpRange-14

2008-03-19 Thread Johnny Bufu

On 19-Mar-08, at 2:51 AM, Noah Slater wrote:

 On Tue, Mar 18, 2008 at 07:54:20PM -0700, Kevin Turner wrote:
 A request for an OpenID Identifier SHALL NOT issue a 303 response.

 This is even worse and also backwards incompatible. All the OpenIDs  
 that
 currently use 303 redirects, including mine, will all break.

By all standing definitions (both v1.x and v2.0), your http:// 
bytesexual.org/ URL is *NOT* an OpenID. You are the only one calling  
and expecting it to be, based on your interpretation and proposed  
changes.

 Well, from my perspective it seems like eventually most people on  
 the list
  agreed that it was an issue as outlined by my use case. In any  
 case, the
  simplest things are often discussed at great length, if for not  
 other reason
  than the colour of the bikeshed, so this is a non sequitur.

Note that there have been objections to your proposal, which have not  
been answered. This effectively accounts to a veto for the proposed  
changes getting accepted.

 On 19-Mar-08, at 7:54 AM, James Henstridge wrote:
 On 19/03/2008, Noah Slater [EMAIL PROTECTED] wrote:
 That seems to be an argument for making no changes.

 No, it's an argument to make the backwards incompatible change  
 that effects
  people in the smallest possible negative way. Your suggestion  
 replaces one
  non-compliant usage of HTTP with another, which is hardly a  
 step forward.

Per the above, the case of making no changes at all still stands.


Johnny


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


Re: Problems with OpenID and TAG httpRange-14

2008-03-19 Thread Johnny Bufu

On 19-Mar-08, at 6:42 PM, Manger, James H wrote:

 [Aside: Browsers displaying the new URL in the address bar after a
 303 See Other is not a counter-example.

Yes, it is.

 The new URL is the address of the displayed response.

The new claimed_id URL is the address of the discovered information  
(which is of interest to the RPs in this case).

 It is NOT the address that will be reused if the
 original request (eg an HTML form submission) is retried.]

How is this relevant?  If the OpenID login form is re-submitted, the  
User-supplied ID will be the first resource, but what difference does  
this make?


Johnny

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


Re: SREG namespace URI rollback

2007-11-01 Thread Johnny Bufu

On 1-Nov-07, at 12:06 PM, David Recordon wrote:
 Sorry it took me a few days, but seems alright to me.  I think a  
 larger question would be if there should be any material  
 differences with SREG 1.1 such as adding a few additional common  
 fields.

I believe Josh's argument back in April was that the URI should be  
the same exactly because there's no difference between 1.0 and 1.1  
(except the openid.ns field / OpenID 2.0 compatibility). Modifying  
the substance of it would invalidate this argument and require  
different namespaces to identify each.

I'm just an implementer here and I'm fine either way, just need to  
know what I can rely on.


Thanks,
Johnny

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


Re: SREG namespace URI rollback

2007-10-26 Thread Johnny Bufu
David, Josh,

Reviving an old thread here...

On 2-Apr-07, at 5:06 PM, Johnny Bufu wrote:

 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.

Can the latest draft of SREG1.1 please be updated as per above?

This is causing two issues at this time:

- OpenID4Java libraries (and Sxip deployments) were implemented as  
per above (and the according design), assuming the update to the spec  
would be done in the near future;
JanRain libraries however still use the published http://openid.net/ 
sreg/1.1 URI for SREG1.1. This leads to interop issues between the two.

- In the recently publish OP comparison chart, Sxipper appears as not  
supporting SREG1.1 (and for good reason from the point of view of  
Will's scripts and published specs).


Thanks,
Johnny

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


Re: Some PAPE Wording Clarifications

2007-10-23 Thread Johnny Bufu

+ [...] For example it is recommended that if the OP
+specified the Multi-Factor Physical Authentication policy  
and the RP
+requested the Multi-Factor Authentication policy, that the RP's
+requirements were met.

This puts undue requirements on the RP implementations. As a design  
principle, I believe the goals were to make required effort and  
adoption and as easy as possible for RPs, and have more happening on  
the OP where possible. I would at least complement, if not replace,  
this patch with:

For example, if the RP requested Multi-Factor and the OP supports  
Multi-Factor Physical, it is recommended that the OP includes both  
policies in the response.

As I argued on the osis list, the OP is in the best position to make  
judgments about the qualities of its authentication mechanisms, and  
it should respond to the point to the RP's requests. What if the RP  
knows what Multi-Factor means, but has no idea (and no interest) in  
Multi-Factor-Physical?


Johnny

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


Re: More questions about openid.ax.update_url

2007-10-22 Thread Johnny Bufu

On 22-Oct-07, at 3:23 AM, James Henstridge wrote:
 If the RP does not store any user attributes (and requests them with
 each transaction from the OP), why does it want to be updated when
 the user changes an attribute value at their OP?

 What I meant was that the RP would act as a cache for the user details
 stored in the OP.

 So the RP would not provide a form letting the user change their
 profile details, instead advising them to make the changes at their
 OP.  The changes would then be communicated back to the RP via an
 update_url message.

That's a possibility, but I think it would be poor user experience  
for the RP to tell the user in plain text go to the OP and then come  
back.

Attribute Exchange also has a store message: the user can update  
their data at the RP, and if the RP thinks that piece of data may be  
useful in other places it can 'store' it at the OP (user has to  
confirm etc, but the whole process is specified and can be automated).

 3. Some portion of users enter an OP identifier URL into the login
 page on the RP (i.e. they are using directed identity).

 4. The RP does not want to ask the user to authenticate twice,  
 even if
 they are creating an account.


 With this setup, it is highly likely that the RP will send multiple
 openid.ax.update_url requests for some users.

 I believe this happens because of the incompatible RP requirements
 you listed at step 2.

 Here, I meant that the RP is likely to send multiple authentication
 requests with openid.ax.mode=fetch_request and openid.ax.update_url
 fields, since it doesn't know that it has already asked for updates
 for the particular identity.

If it's a stateless RP, then I agree - there can be some overhead.

Otherwise, the RP can use the browser session (or even a  
transaction_id in the return url) to keep track of which user is  
which, what data was requested for each one etc. So not really a AX  
protocol issue as I see it.


 For standard authentication requests, the RP will know whether it  
 has
 previously requested updates, but in the directed identity case we
 don't know what claimed ID will be picked at the time of making the
 request.  So in some cases the RP will ask for updates for an OpenID
 that they are already receiving updates for.

 So the question is what should an OP do if it receives multiple
 requests for updates for a particular claimed identifier with the  
 same
 ax.update_url or realm value?  Should it treat the latest request as
 superseding the previous ones?

 If the (claimed_id, update_url) pair is the same the OP already has
 it on file and doesn't need to do anything extra when processing the
 update_url in the fetch request.

 Okay, that is good to know.  It seems like a good reason not to
 include a transaction ID or similar in the update_url like the
 example in the specification then.

 If the two requests for updates ask for different sets of attributes
 (as might happen after upgrading the software on the RP), could the OP
 decide to throw out the old update request,

The OP should throw it away only when it receives a 404 on the  
update_url.

 or should it send updates for the union of the two requests?

As the user updates their data at the OP, the OP can optimize the  
updates it sends out (as long as they match the requests and the user  
has approved them).


Johnny

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


Re: [OpenID] identify RP when it gets OpenID URL

2007-10-17 Thread Johnny Bufu

On 16-Oct-07, at 7:58 PM, Manger, James H wrote:

 Use case: Alice wants to use different OPs for different RPs, while  
 keeping the same URL (eg http://alice.example.net/). For instance,  
 when logging into a service hosting her backups she wants to use an  
 OP that requires a one-time password from a hardware token for each  
 access. However, when leaving comments on blogs Alice wants to  
 authenticate using an OP that only requires a password and uses a  
 persistent cookie so she only has to log in once a day.

I believe there's a cleaner way to address this, that would not  
complicate the things that Alice needs to know about the inner  
workings of OpenID (and without her having to use different  
identities for different purposes):

The PAPE-enabled backup service requests that the OP authenticates  
Alice in a manner compliant with certain policies, that are  
satisfactory to Alice's security requirements for a backup service.


Johnny

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


Re: More questions about openid.ax.update_url

2007-10-17 Thread Johnny Bufu
Hi James,

On 17-Oct-07, at 2:42 AM, James Henstridge wrote:

 I have a few more questions about the update_url feature of OpenID
 attribute exchange that I feel could do with answers in the
 specification.

 For the questions, imagine an OpenID RP with the following properties:

 1. The RP provides a unified login/signup workflow, so that if a user
 signs in with a previously unused OpenID a new account is created.

 2. The RP does not manage any user details, instead requesting them
 via attribute exchange during login, and through updates provided via
 the openid.ax.update_url protocol.

If the RP does not store any user attributes (and requests them with  
each transaction from the OP), why does it want to be updated when  
the user changes an attribute value at their OP?

Maybe I'm not understanding the flow and what the RP is supposed to  
do with a new value sent to the update_url.

 3. Some portion of users enter an OP identifier URL into the login
 page on the RP (i.e. they are using directed identity).

 4. The RP does not want to ask the user to authenticate twice, even if
 they are creating an account.


 With this setup, it is highly likely that the RP will send multiple
 openid.ax.update_url requests for some users.

I believe this happens because of the incompatible RP requirements  
you listed at step 2.


 For standard authentication requests, the RP will know whether it has
 previously requested updates, but in the directed identity case we
 don't know what claimed ID will be picked at the time of making the
 request.  So in some cases the RP will ask for updates for an OpenID
 that they are already receiving updates for.

 So the question is what should an OP do if it receives multiple
 requests for updates for a particular claimed identifier with the same
 ax.update_url or realm value?  Should it treat the latest request as
 superseding the previous ones?

If the (claimed_id, update_url) pair is the same the OP already has  
it on file and doesn't need to do anything extra when processing the  
update_url in the fetch request.

 [I am not sure whether checking (claimed_id, realm) or (claimed_id,
 ax.update_url) pairs would be more appropriate in the above].


Johnny

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


Re: More questions about openid.ax.update_url

2007-10-17 Thread Johnny Bufu

On 17-Oct-07, at 2:42 AM, James Henstridge wrote:

 The next question is how much information from the original OpenID
 authentication request/response can the RP expect to be included in
 the subsequent update responses.

Attribute Exchange is an OpenID extension, so a full/valid/positive  
assertion must be sent each time with an attribute exchange response.

 If the original request was for
 openid.claimed_id=http://www.jamesh.id.au/ and
 openid.identity=http://example.com/jamesh, will those values be
 included in future updates responses?

Being an extension, it is assumed that the RP has completed  
successfully the OpenID verification and has identified the user by  
the claimed_id in the positive assertion.

Therefore the RP has identified the correct user when it is  
processing the AX fetch response sent to an update_url.

 Looking at it from the other side, an OP implementer would want to
 know how much information from the request needs to be stored in order
 to satisfy future update responses.

I believe this is specified already:

If present, the OpenID Provider may re-post the fetch response  
message to the specified URL at some time after the initial response  
has been sent, using a OpenID Authentication Positive Assertion.


Johnny

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


Re: More questions about openid.ax.update_url

2007-10-17 Thread Johnny Bufu

On 17-Oct-07, at 2:42 AM, James Henstridge wrote:

 The next one is not so much a question as an observation: As an
 identity URL may change its delegation over time (possibly without the
 underlying OP's knowledge), it is possible that an RP will receive
 updates from an OP that is not authoritative for the claimed ID.

 So in addition to checking the signature on the unsolicited OpenID
 response, an RP must perform discovery on the claimed ID to verify
 that the OP is correct.  I could imagine an RP missing this step when
 implementing the spec.

Checking the signature and discovered information are requirements in  
the core OpenID protocol.

See 11.  Verifying Assertions :
http://openid.net/specs/openid-authentication-2_0-12.html#verification

Johnny

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


Re: PAPE Extension Specification

2007-10-11 Thread Johnny Bufu

On 8-Oct-07, at 4:56 PM, Jonathan Daugherty wrote:

 # Yep, the idea is for the PAPE spec to define a few generic and
 # agreed upon policies and then RPs and OPs can create others.  Thus
 # if there isn't agreement on a policy, there would be multiple policy
 # URIs.  Same concept as in Attribute Exchange.

 Using policy URIs to indicate certain modes of authentication is a
 fine idea, but that doesn't really address the original issue: the
 spec does not define active (direct) authentication.

Agreed. PAPE spec should define one such policy that's acceptable for  
most of the OPs/RPs (and tie auth_age to it), leaving the possibility  
open for anyone to define other similar policies.

This could be a bit tricky to specify if there's another parameter  
involved, but we should be able to come up with a solution.

Johnny

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


Re: [OpenID] Announce: OpenID Authentication Draft 12 (finally)

2007-08-29 Thread Johnny Bufu

On 29-Aug-07, at 12:19 AM, Peter Williams wrote:
 Why do I care so much about a #?

 Discovery in draft#12 a required security procedure - used when
 verifying the validity of an Auth Response.

I agree: everything starts and then relies on discovery; if it's  
broken nothing works. It's patched now in svn rev 359.

Thanks again Peter for finding this before the spec became final!


Johnny

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


Re: OpenID Provider Authentication Policy Extension

2007-08-24 Thread 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


Re: Differentiating between User Identifier and OP Identifier

2007-07-31 Thread 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 CanonicalID 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

2007-07-31 Thread 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: Using XRI Proxy Resolvers in OpenID discovery

2007-07-30 Thread 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: Differentiating between User Identifier and OP Identifier

2007-07-30 Thread 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 CanonicalID tag, but not the
 ProviderID tag. A one line context of the ProviderID tag would  
 help.

 6. Last line is confusing. Where would a CanonicalID 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: OpenID Provider Authentication Policy Extension

2007-07-23 Thread 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: OpenID Attribute Exchange Protocol questions

2007-07-10 Thread 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.alias with a value of 0 together with its
  corresponding openid.ax.type.alias 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

2007-07-10 Thread 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 Attribute Exchange Protocol questions

2007-07-06 Thread 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.alias with a value of 0 together with its  
 corresponding openid.ax.type.alias 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

2007-07-05 Thread 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: No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table)

2007-06-08 Thread 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

2007-06-08 Thread 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

2007-06-08 Thread 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: Questions about IIW Identifier Recycling Table

2007-06-07 Thread 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: The WordPress User Problem (WAS: RE: Specifying identifier recycling)

2007-06-05 Thread 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 link rel='me' / 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) We use public/private key pairs, though this has the 

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

2007-06-05 Thread 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

2007-06-05 Thread 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)

2007-06-05 Thread 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)

2007-06-05 Thread 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:

 a href=http://josh.example.com/#this-is-intended-for-machine- 
 consumption
  http://josh.example.com//a

 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: Specifying identifier recycling

2007-06-03 Thread 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: Specifying identifier recycling

2007-06-02 Thread 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: Review of Yadis section in XRI Resolution 2.0 WD11

2007-05-31 Thread 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

2007-05-31 Thread 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

2007-05-30 Thread 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

2007-05-30 Thread 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

2007-05-30 Thread 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

2007-05-30 Thread 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: Re-defining the Key-Value format

2007-05-29 Thread 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:
openid.return_to=http://example.com/f%E4rber
 vs.
openid.ax.foo.return_to=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 with that, then  
no encoding (newline escaping) would be needed in AX, so there would  
be no conflict.


 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
 [reference]
  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

 Otherwise, the extra stuff is still there but duplicated in every
 extension that needs it. No good.

 - it would add another

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

2007-05-28 Thread 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  
 [reference]
  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.). Unencoded bytes would  
 have
 to use the %-encoding, rougly doubling the size. Unencoded  
 bytes also
 create problems if implementations think they should be UTF-8,  
 e.g.
 if perl strings are used.]

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

 I think it's much simpler if the specification of the field value  
 format
 just says UTF-8 or Base64

The receiving party would need

Re: Realm spoofing spec patch

2007-05-25 Thread 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

2007-05-25 Thread 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: clarifying section 11.2 in draft 11 for HTML discovery?

2007-05-24 Thread 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

2007-05-24 Thread 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.alias=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

2007-05-24 Thread 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=specificationspath=% 
2Fattribute_exchange%2F1.0%2Ftrunk%2Fopenid-attribute- 
exchange.htmlrev=0sc=0


Johnny

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


Re: Final outstanding issues with the OpenID 2.0Authenticationspecification

2007-05-18 Thread 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:
 +  t
 + As discussed in the xref
 +target=compat_modeOpenID Authentication 1.1
 +Compatibility mode/xref 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.
 +  /t

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 LINK tag with attributes rel set to openid.server and  
 href set to an OP Endpoint URL
   A LINK 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?

2007-05-18 Thread 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: encoding newlines in attribute values

2007-05-08 Thread 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=specificationspath=% 
2Frev=0sc=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: encoding newlines in attribute values

2007-04-30 Thread 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

2007-04-27 Thread 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

2007-04-20 Thread 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


encoding newlines in attribute values

2007-04-18 Thread 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


Attribute Exchange draft 5

2007-04-10 Thread 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: SREG namespace URI rollback

2007-04-07 Thread 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: Moving AX Forward (WAS RE: SREG namespace URI rollback)

2007-04-06 Thread 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)

2007-04-06 Thread 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: [Idschemas] Moving AX Forward (WAS RE: SREG namespace URI rollback)

2007-04-06 Thread 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: SREG namespace URI rollback

2007-04-04 Thread 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)

2007-04-04 Thread 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: SREG namespace URI rollback

2007-04-02 Thread 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
 http://openid.net/sreg/1.0 from
 http://openid.net/extensions/sreg/1.1?


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

2007-04-02 Thread 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

2007-04-02 Thread 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.0openid.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

2007-04-02 Thread 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

2007-04-02 Thread 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

2007-04-02 Thread 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

2007-04-02 Thread 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:
http://openid.net/svn/listing.php?repname=specificationspath=% 
2Frev=0sc=1

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


modulus and generator optional in association requests

2007-03-20 Thread 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


attribute exchange draft 4 review

2007-02-09 Thread 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.alias 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: Proposal: An anti-phishing compromise

2007-02-02 Thread 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

2007-02-02 Thread 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

2007-02-02 Thread 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


Re: OpenID Attribute Exchange 1.0 draft 4

2007-01-31 Thread 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.stuff.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.alias to openid.ax.type.alias

 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: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman anOpenID?

2007-01-03 Thread 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


Re: HTML-Based Discovery with OP Identifiers

2006-12-28 Thread 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

2006-12-28 Thread 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: Comments on Auth 2.0 - Pre-Draft 11

2006-12-15 Thread 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=specificationspath=% 
2Frev=236sc=1


Johnny

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


Re: Comments on Auth 2.0 - Pre-Draft 11

2006-12-12 Thread 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: Comments on Auth 2.0 - Pre-Draft 11

2006-12-11 Thread 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 assume it's intended to be passed (eventually) to a human behind  
 the party receiving it.

 My point is that you assume and I assume and it would be good  
 if we all assumed the same. Which is why I'm proposing to at least  
 put a SHOULD in there for that assuming.


Re: Comments on Auth 2.0 - Pre-Draft 11

2006-12-09 Thread 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 be automated, such as by using JavaScript.


Done - your wording is clearer, but your reasoning and conclusion  
about the previous wording weren't exactly 

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

2006-11-21 Thread 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


HTTP response code

2006-10-18 Thread 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