Re: Backporting the 2.0 extension mechanism to 1.1
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
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: SREG namespace URI rollback
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
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
+ [...] 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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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)
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)
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
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)
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)
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
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
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
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
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
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
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
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
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
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)
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
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
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?
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
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
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
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?
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
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
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
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
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
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
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
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)
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)
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)
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
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)
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
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
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
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
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
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
modulus and generator optional in association requests
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
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
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
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
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
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?
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
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
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
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
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
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
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
HTTP response code
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
