RE: [OpenID] identify RP when it gets OpenID URL
The User-Agent field does not have the right semantics. I hope that field could be used, for instance, to notice which Relying Parties are using a particular version of Janrain’s Java library for OpenID. It is probably reasonable for Bloglines, Google etc to identify themselves in the User-Agent field as they probably use proprietary purpose-built clients. Most OpenID RPs will not use proprietary clients. The From field feels more appropriate for this OpenID purpose. From: John Panzer [mailto:[EMAIL PROTECTED] Sent: Wednesday, 17 October 2007 2:36 PM To: Manger, James H Cc: specs@openid.net Subject: Re: [OpenID] identify RP when it gets OpenID URL Wouldn't User-Agent: be equivalent, and have prior art (feed readers such as Bloglines identify themselves via User-Agent)? Manger, James H wrote: … “The Relying Party MUST include a From HTTP header field in each HTTP request made during discovery. The From field holds an email address for the RP (eg From: [EMAIL PROTECTED]) [RFC2616]. This enables the discovered information to vary based on the RP. The From field is not authenticated so it is not appropriate to use for access control.” … ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] identify RP when it gets OpenID URL
On 17/10/2007, Manger, James H [EMAIL PROTECTED] wrote: Other solutions: OPs can offer different authentication mechanisms based on the openid.return_to or openid.realm parameter in an authentication request. However, the user has less flexibility when they have to relying on OPs. If the primary aim is just to let the user set a policy on how carefully they should be authenticated when talking to particular RPs, why wouldn't this alternative be appropriate? You are trading complexity at the OP end for complexity at the discovery/delegation end. Or are you trying to address a slightly different problem? Maybe one of: 1. using an OP that is not publicly accessible for certain operations 2. using an RP that will only authenticate people using a particular OP. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
More questions about openid.ax.update_url
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. 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. 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? [I am not sure whether checking (claimed_id, realm) or (claimed_id, ax.update_url) pairs would be more appropriate in the above]. 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. 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? 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. 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. James. ___ 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: [OpenID] identify RP when it gets OpenID URL
PAPE may be another approach (to support per-user per-RP login policies). It certainly will not always be “cleaner”. It is not a reason against enabling a discovery-based approach. This PAPE suggestion requires the RP and OP to implement what the user wants. A discovery-based approach only requires the web site hosting the user’s identifier to implement what the user wants. 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. PAPE must be implemented by the backup service AND the OP. Alice’s policy must be expressible in PAPE’s language. The backup service must have a GUI for Alice to choose her security requirements. The backup service has to remember per-user login requirements – which is rather at odds with a main point of OpenID of the RP not having to be involved with how Alice is authenticated. Every other RP where Alice wants to tweak her login policy also needs to support this… Please don’t make this the only way to implement this style of feature. There have always been 4 entities in an OpenID login: the user (with a browser); the OP; the RP; and the web site hosting the user’s identifier. The last entity can simply be a static HTML page, which is a huge bonus. Identifying the RP to this entity enables (but doesn’t require) it to be more than a static page – when that is useful (ie for users, circumstances and functions where it turns out to be the easiest implementation point). _ From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Thursday, 18 October 2007 4:15 AM To: Manger, James H Cc: specs@openid.net 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. From: Manger, James H Sent: Wednesday, 17 October 2007 12:59 PM To: 'specs@openid.net' Subject: [OpenID] identify RP when it gets OpenID URL … Add the following paragraph at the end of section 7.3 Discovery: “The Relying Party MUST include a From HTTP header field in each HTTP request made during discovery. The From field holds an email address for the RP (eg From: [EMAIL PROTECTED]) [RFC2616]. This enables the discovered information to vary based on the RP. The From field is not authenticated so it is not appropriate to use for access control.” … ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID 2.0 finalization progress
My understanding is that we need to get the IPR process finalized, then cross all the t's and dot the i's from the intellectual property perspective for the 2.0 spec(s), and then declare 2.0 to be final. Would be too embarrassing if we declared a spec final and then discovered that it did not meet our own IPR requirements re patents, for example, wouldn't it? On Oct 15, 2007, at 16:00, Dick Hardt wrote: +1 On 15-Oct-07, at 3:02 PM, Josh Hoyt wrote: Hello fellow OpenID spec participants, As I wrote in August [1], it's time to get the specification declared final. We've had quite a while now for implementations and specification feedback. Here at JanRain, we've implemented the draft specification in Python [2] and PHP [3], and I know that the folks at Sxip have implemented and deployed it in Java [4]. I know that at least those implementations have beed tested against each other, and worked successfully. I haven't heard of any new spec issues raised from implementation. As such, I am in favor of declaring Draft 12 the final draft and blessing it as OpenID 2.0. Do the other specification editors agree that now is the time to declare OpenID 2.0 finished? Josh Hoyt [EMAIL PROTECTED] OpenID: http://j3h.us/ 1. http://openid.net/pipermail/specs/2007-August/001953.html 2. http://openidenabled.com/python-openid/ 3. http://openidenabled.com/php-openid/ 4. http://code.google.com/p/openid4java/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
