Re: Defining how OpenID should behave with fragments in the return_to url
On Wed, Mar 25, 2009 at 3:33 AM, Luke Shepard lshep...@facebook.com wrote: One crude way to do it would be to have the caller specify that they want the return_to args simply appended instead of integrated into the URL- perhaps an argument like openid.append_return_to_params=true. But that sounds hackish and I’d love to hear feedback on a better way to do this. How would this interact with OpenID providers that respond via a POST request instead of a GET? This is something they are permitted to do according to the spec, and may decide to do so even if the authentication request was started with a GET if the response is large enough. If it helps, you could reproduce such a response with a form like: form action=http://open.lukeshepard.com/openid_receiver.html?query#hash; method=post accept-charset=UTF-8 input type=hidden name=openid.ns value=... ... input type=submit value=Submit /form This proposal sounds like something that will work most of the time but fail in a number of valid cases. It'd be nice to support the popup based authentication workflow well, but I am not convinced that relying on this quirk is the right way to do so. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Defining how OpenID should behave with fragments in the return_to url
On Thu, Mar 26, 2009 at 1:49 AM, Martin Atkins m...@degeneration.co.uk wrote: James Henstridge wrote: On Wed, Mar 25, 2009 at 3:33 AM, Luke Shepard lshep...@facebook.com wrote: One crude way to do it would be to have the caller specify that they want the return_to args simply appended instead of integrated into the URL- perhaps an argument like openid.append_return_to_params=true. But that sounds hackish and I’d love to hear feedback on a better way to do this. How would this interact with OpenID providers that respond via a POST request instead of a GET? This is something they are permitted to do according to the spec, and may decide to do so even if the authentication request was started with a GET if the response is large enough. This is a good point, but it seems like again it can be worked around by making openid_reciever.html accept POST requests. Unlike the query string, this can't be done completely client side, but it ought to be reasonably simple to set up some kind of rewriterule or other indirection trick to make POST requests to openid_reciever.html actually get served by a non-static endpoint. Any intermediate caches would also drop their cached versions when they see a POST request too (assuming they follow the standards), but I suppose it'd still be a win if the POST requests are infrequent. This is starting to become a lot more complicated than the simple static return_to page from the initial proposal though. To be honest, I'd be surprised if POST requests from OP to RP worked interoperably today, but the trick of using the # on the end of the return_to URL to signal to a supporting OP I'm trying to do this completely client-side, so don't do a POST request works here too. Disallowing post responses limits the use of the more verbose extensions (e.g. attribute exchange). While this might be acceptable for Luke's particular use case, it might leave it unsolved for others. It might be worth going back to basics and considering whether there are other solutions. The stated aim was to provide the best user experience possible for running an OpenID authentication request through a pop up window and then communicating the results back to the main window. Luke's proposal is one possible solution, but I wouldn't want to impose limitations on the specification if there is an alternative that also solves the problem. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: CLARIFICATION: Is OpenID Discovery Optional?
2009/1/7 David Fuelling sappe...@gmail.com: All, Wondering if anybody, especially the original OIDF Board and any contributor's to the OpenID Auth 2.0 spec could comment on this question for me. Is OpenID Discovery, as seen in section 7.3 of the Auth spec, optional? More specifically, is the information returned by discovery meant to be Authoritative for a particular OpenID or OP Endpoint, or is it merely meant to be Informative. This seems like a bit of a weird question to me. The way the OpenID is structured, I can easily write an OpenID server that will respond with properly signed positive assertion responses for identity URLs that I don't control, should an RP decide to talk to it. This won't help me impersonate anyone to an RP though because the discovery information doesn't point to my server. Being the link from the identity URL to the OpenID provider, I don't see how you could treat it as anything other than authoritative. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Accessing Service on Behalf of the User--supported in OpenId?
On Thu, Aug 21, 2008 at 12:49 AM, Scott Battaglia [EMAIL PROTECTED] wrote: Thanks for the reply...some comments in-line! On Fri, Aug 15, 2008 at 6:26 AM, James Henstridge [EMAIL PROTECTED] wrote: 2008/8/15 Scott Battaglia [EMAIL PROTECTED]: snip / 1. Do you guys support accessing a service on behalf of a user. In CAS we call this proxying on behalf of the user. But essentially, if you're say, a portal, and you need to access the grades, you would retrieve a CAS proxy ticket and give it to the grades service which would resolve that to the user as well as the chain of where it came from. 2. Use OAuth. The portal acquires an access token to the grades service. This involves sending the user to the grades service to authenticate (which might be done using OpenID). The portal can then use the access token to request the data directly from the grades service. This seems like a more viable solution. This is probably more of a OAuth user list question but I figure I'll check here first. It doesn't look like OAuth does attribute exchange, is that true? Or is there an extension we could use (or a standard way to add extensions). My guess is that would start to get a little weird because if there's no interaction then there is no way for a user to approve/deny attribute exchanges unless there's a central decision made about attribute releases (which may work for us, but probably doesn't work in a general case) OAuth really only defines two things: 1. how the consumer acquires an access token used to talk to the service provider on behalf of the user. 2. how communication between the consumer and service provider is authenticated. It doesn't define what the service provider's API look like, so that part would be up to you to define. Some of the other stuff is more related to local SSO needs than the actual protocol, but I'll ask anyway: 1. Do you support a method of determining whether someone has authenticated already (in CAS we call it gateway)? For us it relies on the fact that you always point to one CAS server, which obviously doesn't need to be true in the case of OpenId.However, in the scenario where you know there is only one authenticating server, is this possible? If you are implementing a closed single sign-on system, you can do the following: 1. Make the OpenID provider implement an identifier select endpoint. 2. Make the OpenID provider automatically authenticate users who have already authenticated (perhaps just to known sites). 3. For the relying party sites, if the user is unknown (according to local session cookie), begin an OpenID authentication request to the identifier select endpoint. The result will include the user's identity. The system we're building would most likely include SSO, so most of this would already happen. The additional thing CAS offers is that we won't force you to authenticate if you haven't already, but we will take advantage of the fact that you have if you did already (i.e. for a portal, if you haven't authenticated we'll just show a guest layout, but if you have, we'll actually display your layout). My guess is we'll probably have to propose our own extension for this. If you are designing an open system (user can use whatever provider they want), I don't think there is an answer to this (which provider are you asking whether the user is authenticated to?). We're actually considering developing a two-tier system. Locally, we'll still be interested in using OpenId, but we'd probably point all of our local apps to a central server. Then our central server would be able to handle local users or delegate out to other OpenId servers. If you're using that system, I guess you could define some kind of OpenID extension that requests cancel the authentication request if the user is not authenticated and combine that with an identifier select authentication request. The central server might also help address some of the trust issues that exist with specifications like PAPE. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Accessing Service on Behalf of the User--supported in OpenId?
2008/8/15 Scott Battaglia [EMAIL PROTECTED]: Hi everyone, I'm the lead developer on the JASIG Central Authentication Service, one of the SSO servers that a number of higher education institutions use. Traditionally, CAS has used its own de-facto standard protocol (CAS1 and CAS2) which are similar in concept to much of OpenId 1.1. We have a couple of additional things built in (and you guys have some stuff we don't as optional specifications). As part of the evolution of the CAS SSO server, we've been including support for additional protocols beyond CAS. To date, we can support CAS1, CAS2, SAML 1.1, part of SAML2 and are an OpenID 1.1 provider (the dumb model). We're looking to expand CAS into the realm of federation. We've been looking at SAML2 which while extremely powerful can also be very complex and goes against the concepts we've introduced in CAS1 and CAS2 (i.e. simplicity of protocol). OpenId gives us a much warmer, fuzzy feeling :-), so we're doing some initial analysis of utilizing OpenId 2 as our method for federation (in the nice boxes we've drawn on our white board it seems to work well). I just have a few questions for a comparison of the OpenId protocol vs. the CAS protocol that we're obvious to me. The main question is: 1. Do you guys support accessing a service on behalf of a user. In CAS we call this proxying on behalf of the user. But essentially, if you're say, a portal, and you need to access the grades, you would retrieve a CAS proxy ticket and give it to the grades service which would resolve that to the user as well as the chain of where it came from. There are a few models that can be used for this: 1. The user goes to the grades service and requests that their data get transferred to the OpenID provider via the attribute exchange protocol. When they go to the portal site, the portal can request the data from the OP, again using attribute exchange. Of course, in this model there is no direct contact between the portal and grades service in this model, so the portal would need some way of verifying that the data it got was correct. Digital signatures are probably the answer here, but there is no standard for this yet (there was a proposal for this a while back though). 2. Use OAuth. The portal acquires an access token to the grades service. This involves sending the user to the grades service to authenticate (which might be done using OpenID). The portal can then use the access token to request the data directly from the grades service. Some of the other stuff is more related to local SSO needs than the actual protocol, but I'll ask anyway: 1. Do you support a method of determining whether someone has authenticated already (in CAS we call it gateway)? For us it relies on the fact that you always point to one CAS server, which obviously doesn't need to be true in the case of OpenId.However, in the scenario where you know there is only one authenticating server, is this possible? If you are implementing a closed single sign-on system, you can do the following: 1. Make the OpenID provider implement an identifier select endpoint. 2. Make the OpenID provider automatically authenticate users who have already authenticated (perhaps just to known sites). 3. For the relying party sites, if the user is unknown (according to local session cookie), begin an OpenID authentication request to the identifier select endpoint. The result will include the user's identity. If you are designing an open system (user can use whatever provider they want), I don't think there is an answer to this (which provider are you asking whether the user is authenticated to?). 2. Similar to above, we support a concept of opting-out and forcing re-authentication. So an application that contains SSNs may basically tell the authentication server, I don't care if they've authenticated already, do it again. The PAPE extension would be appropriate here: http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-02.html A relying party site can ask the OP to reauthenticate the user if they were previously authenticated more than N seconds ago (N can be zero). Of course, there is nothing to prevent an OP from lying about reauthenticating the user. If that matters to you, then only accept OpenID providers you trust. The last question: We don't actually do this in CAS yet, but we've seen it and a few people have asked for it. Is there a way to pass information along to say something like I need them to authenticate via username/password, or cert, or LOA2 or higher? Again, the PAPE extension should handle this. Thanks for any answers you guys can provide. We'll be continuing to do research into how OpenId2 fits into the CAS world, but I wanted to see if I could get some of these basic protocol comparison questions out of the way. James. ___ specs mailing list specs@openid.net
Re: Backporting the 2.0 extension mechanism to 1.1
On Wed, Aug 13, 2008 at 3:56 AM, Martin Atkins [EMAIL PROTECTED] wrote: The Net::OpenID::Consumer perl library as it currently stands will not support PAPE in 1.1-mode messages since the openid.ns.alias mechanism is only used in 2.0 mode. I'd like to change this to use the 2.0 scheme in 1.1 (with a special case for sreg) but I'm only comfortable doing that if there's a specification (or errata) that explicitly allows it. Perhaps you could do something similar to the python-openid library? If you are writing support for a new extension, you can use the registerNamespaceAlias(uri, tag) function from the openid.message module. When parsing OpenID 1.x messages (which can be determined by checking for the absence of openid.ns), it uses these namespace aliases to map the prefixes to URIs. Outside of the message parsing code, you can work purely in terms of namespace URIs, which limits the amount of code that needs to know about 1.x vs. 2.0. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Non-interactive logins
On Wed, Jul 16, 2008 at 12:38 PM, Anders Feder [EMAIL PROTECTED] wrote: tir, 15 07 2008 kl. 21:28 -0700, skrev John Panzer: And of course any number of extensions could be created to obtain an access token via an alternate path, after which normal OAuth can be used. Sure, but isn't this equally true for OpenID? Most OpenID RPs maintain some kind of session for the user, but that is not required by the spec (some require OpenID auth to perform each action). In contrast, the whole point of OAuth is to generate an authorisation token that can be used for machine access to a site multiple times in the future. The OAuth service provider might use OpenID when deciding whether to grant an authorisation token to a client to access the site on behalf of a particular user if appropriate. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Google OpenID is now live
On 10/04/2008, Vinay Gupta [EMAIL PROTECTED] wrote: I think that kind of misses the point. The *namespace* that google manages is now open for business as an OpenID provider. It's an unanticipated side-effect of the APIs. I think it's kind of a big deal, actually, in terms of how OpenID is right from an engineering perspective and how it can spread in unexpected ways. If only login were so easy. This service seems pretty much equivalent to Simon Willison's idproxy.net service for Yahoo accounts. The big difference between this sort of service and actial OpenID Provider support from Google/Yahoo is a matter of trust. With an OP run by Google, the user needs to trust Google. With this OP, the user needs to trust whoever is running the OP not to impersonate them. Given the lack of contact information, I'd be hesitant to use identities managed by that service and would not recommend others rely on it. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Google OpenID is now live
On 10/04/2008, Brad Fitzpatrick [EMAIL PROTECTED] wrote: On Thu, Apr 10, 2008 at 12:40 AM, James Henstridge [EMAIL PROTECTED] wrote: On 10/04/2008, Vinay Gupta [EMAIL PROTECTED] wrote: I think that kind of misses the point. The *namespace* that google manages is now open for business as an OpenID provider. It's an unanticipated side-effect of the APIs. I think it's kind of a big deal, actually, in terms of how OpenID is right from an engineering perspective and how it can spread in unexpected ways. If only login were so easy. This service seems pretty much equivalent to Simon Willison's idproxy.net service for Yahoo accounts. The big difference between this sort of service and actial OpenID Provider support from Google/Yahoo is a matter of trust. With an OP run by Google, the user needs to trust Google. With this OP, the user needs to trust whoever is running the OP not to impersonate them. Given the lack of contact information, I'd be hesitant to use identities managed by that service and would not recommend others rely on it. James, openid-provider.appspot.com was written by a Google engineer, Ryan Barrett, who also did most the work (including all the initial work) on Blogger's OpenID support: References: http://appgallery.appspot.com/about_app?app_id=agphcHBnYWxsZXJ5chMLEgxBcHBsaWNhdGlvbnMYrwIM http://snarfed.org/space/2008-04-07_google_app_engine_launched http://snarfed.org/space/2007-12-02_openid_comments_in_blogger Okay. It wasn't clear who was running the service just by looking at the URL originally posted. Further, App Engine apps don't process user credentials directly. They go through an OpenID-like auth process with Google, who actually processes the email/password and tells the App Engine app that somebody logged in, at what email. You can verify this yourself by looking at the form targets and HTTP traffic. See: http://code.google.com/appengine/docs/users/ So I'd say you can pretty much trust an openid-provider.a.com assertion that the person has a Google account. But like others have said, it's not an official Google product. I realise that Google's authsub service doesn't reveal a user's email + password to the relying site (in this case openid-provider.appspot.com). If you are using an OpenID provider that I control, you are trusting me not to add a backdoor that lets me authenticate to RPs as your identity URL. And given the way OpenID works, I'd have a pretty good idea of which RPs to go after. Based on the info in the links you provided it is probably safe to trust the site not to do these things, but it is not clear from the information on that site alone. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Using email address as OpenID identifier
On 02/04/2008, Paul E. Jones [EMAIL PROTECTED] wrote: A solution that matches closer with what the user expects would be to map [EMAIL PROTECTED] to a claimed ID of mailto:[EMAIL PROTECTED]. The average user is not going to know what mailto:; is. The mailto: transition would be something done internally by the RP. The RP could (and probably should) display email addresses without the mailto:; prefix to the user. This is similar to the way RPs store persistent XRIs as the user's claimed ID but are encouraged to display the reassignable XRI. For (2), I'd suggest a solution that maps the email address to either directly to an OpenID endpoint (using the claimed ID as local ID), or to an XRDS file. A DNS based solution seems fine here (either your NAPTR idea, or TXT records as suggested in replies to your post). NAPTR queries and transformations are straight-forward. It's just a regular expression transformation from something that looks like an e-mail address to the real OpenID ID. But, again, I don't really care how it works. But, for the benefit of those who are not so technically capable, I believe it's got to be super, super trivial. NAPTR would work extremely well, I think, and would be fast. Any OpenID OP could provide an e-mail style identifier and it would certainly be a motivator for anybody providing e-mail service to also OpenID enable their subscriber's e-mail addresses. I don't think there is a need to introduce an HTTP identity URL here. If you're going to use an email address as an identity, then use an email address as an identity. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Using email address as OpenID identifier
On 02/04/2008, Paul E. Jones [EMAIL PROTECTED] wrote: Folks, I've seen discussion here and there on the use of the e-mail address as the OpenID identifier. Perhaps this one says it best: http://www.majordojo.com/2007/02/what-openid-needs.php I share many of same opinions. If OpenID is going to be practically usable by the average person, we cannot require the person to remember some very complex identifier. When I signed up for Yahoo's OpenID service, it presented me with a hideously ugly URL that looked similar to a base64-encoded string. I could not begin to tell you what it was. Fortunately, Yahoo allowed me to define my own, friendlier name. Still, the ID is not one that the average user will remember or get right. While the e-mail address does not have to be the one's ID, it can certainly serve as an alias. Suppose, for example, that the DNS records at Yahoo contained the following entry: yahoo.com. IN NAPTR 100 10 U OpenID2 ^(.+)@(.*)$!https://me.yahoo.com/\1!i; This would allow a Relaying Party to accept an e-mail address and perform a simple transformation to get the real URL identifier. Of course, this does not mean that the existing URL or XRI identifiers are invalid, nor does it mean that the email address has to be a real e-mail address. But, this form would certainly be far simpler for most people to deal use. If your aim is to let people use an email address as an identifier, there are a few questions to answer: 1. when a user enters an email address into an RP, how is the claimed ID derived from that input? 2. given such an input, how does the RP go about discovering the OpenID endpoint URL and local ID for that identity? With answers to these two questions, the remainder of the protocol should function as is. I'm guessing (correct me if I'm wrong) that you're suggesting that this DNS lookup be done as part of (1). This seems like it would cause confusion if the user's ISP changed their DNS, since the user would see their email address as being the real identifier: not the URL that it maps to. A solution that matches closer with what the user expects would be to map [EMAIL PROTECTED] to a claimed ID of mailto:[EMAIL PROTECTED]. For (2), I'd suggest a solution that maps the email address to either directly to an OpenID endpoint (using the claimed ID as local ID), or to an XRDS file. A DNS based solution seems fine here (either your NAPTR idea, or TXT records as suggested in replies to your post). James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Using email address as OpenID identifier
On 02/04/2008, Paul E. Jones [EMAIL PROTECTED] wrote:
Brad,
Your point about DNS limitations is valid. Then again, anybody who will be
offering the open identity server is likely going to have control over their
DNS. Still, I'm not opposed to alternatives.
But, since you brought up the fact that one can enter yahoo.com and get
redirected, I checked and, indeed, several OpenID sites already accept the
e-mail ID as a form of identification—and I can get redirected to either
Yahoo or MyOpenID.com. So, do some of the libraries already check for
e-mail address forms? It seems that perhaps they do!
What you are seeing is probably not what you expect:
from openid.consumer.discover import discover
claimed_id, services = discover('[EMAIL PROTECTED]')
for service in services:
... print 'Local ID:', service.getLocalID()
... print 'Server URL:', service.server_url
...
Local ID: None
Server URL: https://open.login.yahooapis.com/openid/op/auth
claimed_id
'http://www.yahoo.com/'
What is happening is that [EMAIL PROTECTED] is being treated as
http://[EMAIL PROTECTED]/. As http://yahoo.com; results in an
identifier select endpoint that will work for any Yahoo user.
Note that the HTTP username isn't being used for anything here, and
you'll get the same result by just entering yahoo.com. I wonder if
the Yahoo guys had considered this, or if it is just a happy accident?
James.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
Re: Problems with OpenID and TAG httpRange-14
On 19/03/2008, Noah Slater [EMAIL PROTECTED] 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. Given two backwards incompatible changes I hardly see how one which breaks existing OpenIDs is favourable to one which changes how some are handled. That seems to be an argument for making no changes. The change you are proposing is not backwards compatible -- an RP that's decided your identifier is example.com/about would then decide it's example.com/ as soon as it upgrades to the new version, and that wouldn't be good for existing users. I think it should behove the OpenID group to actually estimate how many people might be using 303 redirects in conjunction with an OpenID such as I am before concluding that the change should not be made. I have a sneaking suspicion that I may be the only person. If that is that case, I am happy to inform you that I don't mind the change. You're okay with sites interpreting your ID differently depending on the version of OpenID they support? Aren't you concerned that you'll lose access to your accounts on various RPs if your OP or the RP upgrades? Or do you planning to only talk to RPs that support the new version? I also don't think that such a decision should be based on your assertion that you're the only one who would be affected. The XRDS-resolution-for-HTTP-identifiers (nee Yadis) already provides a mechanism to publish discovery information at a URL which does not have HTML content. Sure, but that doesn't help me and my use case. The code path you are are requiring the implementations to change (OpenID discovery and normalization) is, with the combination of different identifier types, protocol versions, and discovery schemes, already one of the most tangled chunks of code involved. I acknowledge that your proposed change, in isolation, seems simple enough, but that code *really* doesn't need another branching condition in it. Arguing the complexity of the implementation is just wand waving without some concrete evidence to suggest that this would be a complex change. Most HTTP libraries should offer simple hooks into the redirect chain. To maintain compatibility with existing versions of OpenID, RPs would need to perform discovery, and then decide which of two identity URLs to use based on which protocol version is negotiated. Whatever you might say about the existing discovery mechanism, this does seem a lot more complex, since it intermingles discovery with protocol version negotiation. I appreciate the spirit of your suggestion. It's a terrible thing to say oh, we follow standard X, except in the cases outlined in appendix B, which you will have to modify your X-implementation to be aware of. But, practically speaking, the use case is not compelling enough to overcome the cost of change. Again, I don't think you have provided any specifics about the cost of change. We don't know how many people use 303 redirects with OpenID and we don't know exactly how complex a change to the OpenID libraries would be. And it's not like you have an RP implementation that *almost* works except not quite because the libhttp-follow-redirects- and-return-the-content-and-the-final-URL-unless-the-redirect-was-a-303-in-which-case- return-the-intermediate-url function in your web framework is returning something incompatible with OpenID. (Or, if it is, I really want to hear about what HTTP client implementation you're using.) Well, many HTTP clients provide clear hooks into redirect chain. I know that *you* think the semantics are clear, but the fact that knowledgeable people have been haggling over it for weeks on the list suggests that it may not be. 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. So, IMHO, the best way to make this problem go away is to just say that 303s are an invalid way of telling an RP where discovery information is. As I mentioned above, instead of altering how all the existing 303d OpenIDs (again, perhaps I am the only one using OpenID like this) are handled, you would break them all, permanently. RPs will continue to work the way they do now, for backwards-compatibility purposes How are you so sure? Perhaps they will just stop working one day. and anyone publishing OpenID identifiers in the future will be able to find a clear statement about it in the spec. This makes no sense. The current specification
Re: Difference between 1.0 and 1.1
On 12/03/2008, techtonik [EMAIL PROTECTED] wrote: So, if I understand correctly there is no way for consumer to detect which version - 1.0 or 1.1 is used in HTML delegation case, because delegation tags are the same, i.e. link rel=openid.server href=http://www.livejournal.com/openid/server.bml; link rel=openid.delegate href=http://exampleuser.livejournal.com/; so in my case Drupal consumer decides that either 1.0 or 1.1 version of specification is used and makes a request to OpenID server with openid.ns set to either http://openid.net/signon/1.1; or http://openid.net/signon/1.0;. But 1.1 OpenID server doesn't know anything about openid.ns, because it was added only in 2.0 Therefore server fails to authenticate and this should be considered a bug in consumer, which should not send openid.ns at all. If everything above is right then where is the logic and what are the reasons for consumer to send openid.ns=http://openid.net/signon/1.1; at all? OpenID 1.x messages do not contain an openid.ns field. That field was introduced in OpenID 2.0, and states that All messages in OpenID Authentication 1.1 omit the openid.ns parameter. If you are sending requests with openid.ns set to anything other than http://specs.openid.net/auth/2.0; you are going to run into trouble. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: SREG 1.1 Request parameters
On 21/02/2008, Enis Soztutar [EMAIL PROTECTED] wrote: Hi, As far as I understand, the distinction between sreg.required and sreg.optional is entirely in the responsibility of the consumer and there is not reason for the protocol to include this arbitrary division. An OP implementation will just merge the two fields and try to fill them as much as it can. It is a hint from the RP about which pieces of user information it requires. The OP may choose to use that info when asking the user for authorisation to send the data. Of course, the RP needs to handle the case where it doesn't receive some user details it asked for, possibly by getting the user to fill them in when they return from their OP. I propose we merge this two fields for version 1.1. This will introduce another backwards compatibility rule, but I think this design will be better. Introducing new features to the SREG extension seems a bit questionable. If you want to do things that SREG doesn't handle, you'd be better off looking at the attribute exchange extension. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID 3.0
On 04/02/2008, Eddy Nigg (StartCom Ltd.) [EMAIL PROTECTED] wrote: James Henstridge wrote: Of course, the OP is restricted to returning identities that it is authoritative for. This is what allows any yahoo user to enter yahoo.com as their OpenID identifier while still letting RPs tell them apart. Right, that's what I thought...What does it have to return however? Is it enough to return [openid_identity] = https://somenick.domain.com/, [openid_claimed_id] = https://domain.com/ ? That is possible provided that performing discovery on https://domain.com/ gives you https://somenick.domain.com/ as the OP local identifier and uses the given OP. When selecting an identifier, the OP chooses both the local identifier (openid.identifier) and claimed ID (openid.claimed_id). My point was that in cases where you do want to limit things to a single OP, it is worth considering this mode, since it does not require the user to enter any credentials (username or password) at the RP site. Yes, that is rather easy. Somewhat more tricky gets when you want to use a group of providers and ban certain providers. All doable, but not standardized yete.g. white/black lists. As Kevin said, you can always apply that kind of policy at the end of authentication process. You can do that with either OpenID 1.x or 2.0. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID 3.0
On 02/02/2008, Eddy Nigg (StartCom Ltd.) [EMAIL PROTECTED] wrote: Yes, I also wonder why the IDP can't just return the ID. As of now I think it's two steps for this, with the RP explicit requesting it? Or am I wrong with that? When used in directed identity mode, the OP can pick the identity: http://openid.net/specs/openid-authentication-2_0.html#responding_to_authentication Of course, the OP is restricted to returning identities that it is authoritative for. This is what allows any yahoo user to enter yahoo.com as their OpenID identifier while still letting RPs tell them apart. My point was that in cases where you do want to limit things to a single OP, it is worth considering this mode, since it does not require the user to enter any credentials (username or password) at the RP site. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID 3.0
On 02/02/2008, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: Figured I would ask if anyone is interested in brainstorming the next version of OpenID and how it can be used in Enterprise B2B settings and not solely focusing on consumerish interactions. Some things that I would like to see in the next version are: 1. A discussion on how AuthZ can converge with OpenID 2. Modeling of relationships 3. Not allowing an OpenID to be a vector for SQL Injection and putting something around what it should look like I'm not sure what there would be to say in the spec about this: SQL injection is not party of the standard, but rather a feature of some implementations :) 4. A way to indicate to the relying party what level of authentication has occurred such as did the OP check a password, how did it validate a user. Without this, there is no way that a trust model could be established in a credible way. The provider authentication policy extension handles half of this already (telling you what checking the OP did). It does not cover the trust issue though, so without a pre-existing trust relationship there is no reason to believe the PAP assertions. The trust side is something that would be interesting to see addressed in future specs. 5. A way for OpenID relying parties to filter out Ops. In a business scenario, if I run the Sun employee store, I may only want the Sun OP to talk with me. This is already possible with OpenID 2.0: 1. make the Sun OP provide an OP identifier URL that can be used to initiate a directed identity request to authenticate any user of the OP. 2. to authenticate, the Sun employee store would initiate an OpenID request against the URL from (1) rather than asking the user to enter an identity URL. With this setup, the user need not know that they are using OpenID or know what their identity URL is. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID 3.0
On 02/02/2008, Kevin Turner [EMAIL PROTECTED] wrote: On Sat, 2008-02-02 at 08:51 +1100, James Henstridge wrote: 5. A way for OpenID relying parties to filter out Ops. In a business scenario, if I run the Sun employee store, I may only want the Sun OP to talk with me. This is already possible with OpenID 2.0: [snip] This is already possible with OpenID 1.0: Perform discovery on the given identifier. Compare the discovered OP Endpoint to those in your filter. If you do not like what you see, do not proceed. Right. I guess I forgot about that after using directed identity for a few cases just like this. I'd argue that directed identity with a fixed OP URL can provide a nicer workflow for these sort of closed environments though: 1. the RP need not ask for a user name, so all authentication occurs on the OP. 2. If the user is already authenticated to the OP, the user could be authenticated to the RP without having to enter any input (if desired). 3. As mentioned earlier, the user does not need to know their identity URL (or even that they have one) -- they only need ot know the credentials needed to log into the OP. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID 2.0 Section 9.2.1
On 29/10/2007, John Ehn [EMAIL PROTECTED] wrote: I've been reviewing Draft 12, and noticed this section, which I think will cause problems for some systems. 9.2.1. Using the Realm for Return URL Verification OpenID providers SHOULD verify that the return_to URL specified in the request is an OpenID relying party endpoint. To verify a return_to URL, obtain the relying party endpoints for the realm by performing discovery on the relying party (Discovering OpenID Relying Parties). As always when performing discovery, the discovered URL is the URL of the last HTTP response, following redirects. If any redirects are followed when performing discovery on the realm, verification has failed. If discovery has successfuly completed, check to make sure that the return_to URL matches one of the relying party endpoints. A realm may contain a wildcard, and so may not be a valid URL. In that case, perform discovery on the URL obtained by substituting www for the wildcard in the realm. To match a return_to URL against a relying party endpoint, use the same rules as for matching the return_to URL against the realm, treating the relying party's endpoint URL as the realm. Relying party endpoint URLs MUST NOT contain a domain wildcard, and SHOULD be as specific as possible. If verification is attempted and fails, the provider SHOULD NOT send a positive assertion to that return_to URL. Providers MAY cache verified return_to URLs. I think it is a nice idea, however, it does not take into account situations where a Relying Party may not exist on the public Internet. For instance, let's say I have an intranet application. The following is true: The application is located on a host in my office My office is connected to the Internet via a NAT firewall (all internal IP addresses are not accessible from the Internet) My application uses OpenID for authentication A guest worker has been given permission to use my application with their OpenID provided by another company The following should happen: The user will attempt to log in with their OpenID My application will send a request to the OpenID Provider The Provider will attempt to perform RP discovery The RP discovery will fail The OpenID Provider rejects the authentication request As you can see, for this use case, OpenID would no longer be usable. From my reading of the spec, the OP only tries to verify the return_to value if RP discovery succeeds. If RP discovery fails, then return_to verification is not attempted. In the case of an intranet RP (or any other RP that hasn't implemented discovery), any return_to URL that matches the realm should be acceptable. The case where the OP SHOULD NOT return a positive assertion is if: 1. the OP attempts RP discovery 2. RP discovery succeeds 3. the return_to URL is not in the list of discovered RP endpoints James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: More questions about openid.ax.update_url
On 18/10/2007, Johnny Bufu [EMAIL PROTECTED] wrote: 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? 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. Maybe I'm not understanding the flow and what the RP is supposed to do with a new value sent to the update_url. It'd update the cached user details stored by the RP. 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. 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, or should it send updates for the union of the two requests? James. ___ 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 Trusted Authentication Extension
On 31/08/2007, John Ehn [EMAIL PROTECTED] wrote: Well, I've slept on it. I think we have a difference in philosophy. The other Extesions - AX, Simple Registration, etc. - follow the same data flow methodology: RP - UA - OP RP - UA - OP With my proposed workflow, it'd be going through the UA too. The checkid_setup request and id_res response uses indirect communication, so those calls do go through the user agent. I did not specify this explicitly in my previous email because it is implied. So the workflow would look something like this if the data provider needs to authenticate the user: DC - UA - DP - UA - OP DC - UA - DP - UA - OP In the communication between DC and DP, the DC is the RP and the DP is the OP. In communication between the DP and OP, the DP is the RP and the OP is the OP. I believe I'm sticking to the same principles in my spec. We are doing the very same thing when we collect the authentication key (see above). We are even doing the very same thing when we have the sites authenticate with each other. It's just we have a non-human operating the User Agent. In this case, the RP is the destination site, the UA is the client site: RP - UA - OP RP - UA - OP You still want the user involved in the granting of an authentication token though, right? Trying to replace the UA in the authentication workflow is quite a big change, and limits what the OP can do. I think this fits well with what people expect. I also have no problem with having OPs incrementally improve their systems to make them compatible with new extensions. Since there will (eventually) be far more RPs out there than OPs, I think it's reasonable for them to support the bulk of the extension implementation. With your proposal, the user's OP needs to implement an extension. This brings up a few questions: 1. Should the data provider only let users register if their OP implements the extension? What is the benefit to the data provider in enforcing such an extension? 2. If only some users' OPs implement the extension, can the data consumer rely on the protocol at all? In contrast, both the data provider and consumer have an incentive to implement an extension for auth token transfer, so a spec that only requires modifications to those parties seems easier to roll out. What do you think? [snip] Although your implementation is sound, and I like a lot of the ideas, they shift a lot of the responsibility to the party receiving the authentication request. I'm not sure I like the idea of having the burden of implementing both an API and a special pseudo-OP. This also removes the power of having a single Identity management interface at the OP, meaning the user will have to log on to the destination site to invalidate the token. What if the user has 50 of these API connections set up? That's 50 sites to visit in order to manage these tokens. I guess that is a concern. But how often do you expect the data provider to check the user's OP to see if the token is still valid? If it doesn't check often, then revoking the token at the OP level might take a while to take effect. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Trusted Authentication Extension
On 26/08/07, John Ehn [EMAIL PROTECTED] wrote: I have created a draft of a new specification that I think will help to fill a gap in OpenID functionality. What appears to be a newer productivity feature of many websites is the ability to import and utilize information from other sites. For instance, Basecamp provides an API that allows other systems to access user data. This is a great feature, but it currently cannot be done with OpenID, due to the dependence on end-user interaction during the authentication process. The Trusted Authentication Extension provides for the ability for an OpenID Consumer to log in to another OpenID Consumer without user interaction. The end user will be able to create a trusted connection between two OpenID enabled sites, which will allow a client site to access a destination site using the end user's Identity. Please provide your comments and feedback, as they are most appreciated. http://extremeswank.com/openid_trusted_auth.html I think things would be a bit clearer if you made the data provider into a form of OpenID Provider. I think it helps to first consider the case where the data provider is not an OpenID Relying party but instead has its own user account database. If the site acted as an OpenID provider, it would be pretty simple to use an extension to negotiate an auth token to acess data for the user. Simply start an OpenID authentication request, including some field stating that you want access to data. The provider would then include an authentication token in the response that could be used to access the web services. Now lets consider the case where the data provider identifies users by an OpenID. What would happen if the data provider continued to implement an OP, and the data consumer started an OpenID authentication request with it using the user's data provider. This would let us use the same sort of OpenID extension to negotiate the auth token. The data provider could even turn around and perform its own authentication request to verify that the user is who they say they are, since it received the identity URL from the data consumer. So the full workflow might go like this: DC: Data Consumer DP: Data Provider OP: User's OpenID Provider 1. DC sends checkid_setup request to DP for user's identity URL, with an extension asking to negotiate an auth token. 2. DP initiates OpenID authentication for user's identity URL 3. OP verifies user's identity and sends idres reply to DP. 4. DP sends idres reply to DC, including the auth token as an extension in the response. This seems to give similar results to your protocol while introducing fewer new concepts. What do you think? James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Trusted Authentication Extension
On 30/08/2007, John Ehn [EMAIL PROTECTED] wrote: James, Sorry, but I'm having problems following the flow. It seems like an interesting idea, though. Can you provide with a little more information on how these components would interact? Okay. The basic idea was that instead of creating a special protocol for two OpenID relying parties to communicate with each other was for the web services data provider to act as an OpenID provider. So, lets assume that the data consumer wants an auth token for the user identified by http://user.identifier.url. With normal OpenID authentication, you'd perform discovery to find the user's OpenID provider. To request an auth token though we need to talk to the data provider, so instead we skip discovery and perform an authentication request to the data provider's endpoint. The parameters might look something like this: * openid.mode = checkid_setup * openid.claimed_id = http://user.identifier.url * openid.identity = http://user.identifier.url * openid.return_to = http://data.consumer/... * openid.ns.auth = ... * (additional parameters related to the auth token request) The data provider would then decide whether to grant the auth token (possibly by performing OpenID authentication against http://user.identifier.url, and/or asking the user), then send a response back like: * openid.mode = id_res * openid.claimed_id = http://user.identifier.url * openid.identity = http://user.identifier.url * openid.return_to = http://data.consumer/... * openid.ns.auth = ... * openid.auth.token = ... * openid.auth.secret = ... The data consumer knows that the request came from the data provider due to the signature on the OpenID response. The data provider knows which user to create the token for because it was present in the OpenID request. The data provider can verify that the web browser user is that user because control gets transferred to the data provider during the authentication process. This all assumes that the data consumer has already authenticated the user, so knows which identity URL to request a token for from the data provider. I was really trying to keep everything dumb and simple. The concept I was going for was piggy-back on OpenID, but include a way to programmatically log on to the OpenID Provider. The problem I saw with OpenID was that there are about a million different ways to authenticate with an OpenID Provider, from HTML forms to digital certificates. Most require the User Agent to be a web browser. However, there is no standard way to just pass a credential that can prove that you are who you say you are. Well, OpenID authentication requests are designed to let the OP perform whatever checking they want before sending a response. So by making the data provider act as an OP, it has the same freedom (including the freedom to issue its own OpenID authentication request to the user's actual OP). I was trying to solve the problem by coming up with an automatable (if that's a word) way to authenticate with an OpenID Provider. If we have that, there's no need to pass around a special token, because we can just use standard OpenID authentication if we want to log on to another system. So, I proposed just having the Consumer get a key from the OpenID Provider that it can use to automatically authenticate with the Provider in the future. The key is passed through the user when it's granted, because you need the user to approve the whole thing anyway. I think that this makes things more complicated than need be. If you want an auth token from the data provider it seems better to ask the data provider for the key directly, giving it the chance to authenticate the user before responding. This also has the benefit that it does not require any special features from the user's OP -- the extension is purely concerned with the interaction between data consumer and provider. I don't expect this extension to fix all problems. It's only intended to solve a specific use case (website to website info sharing). I am working on two additional extensions which will solve the other problems I see: Sure. I doubt my suggested workflow would help with those use cases either (at least without some additional components). James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Attribute Exchange Protocol questions
[replying to myself] On 10/07/07, James Henstridge [EMAIL PROTECTED] wrote: The only real constraint the authentication spec places on the RP is that it maintain the association for the duration of an OpenID authentication request. With unsolicited response though, there is no prior request that tells us the RP is holding a particular association _right now_. I just realised another difference when working with unsolicited responses. With a normal OpenID authentication request the RP picks an association handle, so we know the RP believes it is valid. However, the OP can use a private association handle in the response if it considers the handle from the request to be invalid. So the OpenID authentication spec does not seem to require either the RP or OP to store an association for longer than ~ one request. In contrast, if a previously established association is used in an unsolicited response there doesn't seem to be any way the RP can tell the OP that it has lost the handle. 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. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Attribute Exchange Protocol questions
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). James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Attribute Exchange Protocol questions
On 06/07/07, Johnny Bufu [EMAIL PROTECTED] wrote: 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). Fair enough. I had not considered that case. 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). 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. Would that be appropriate to include in the spec or some best practices document? 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. 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). 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. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID Attribute Exchange Protocol questions
Hi, I was looking at the attribute exchange protocol spec (draft 5), and had a few questions about it: 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 ... It uses openid.ns.ax twice. It looks like the second occurrence should be openid.ax.mode. The same typo appears in sections 5.2 and 6.1. 2. The spec seems to omit details of how messages should be sent to openid.ax.update_url. In particular: * What format should the message take? Should the OP just send a request with the openid.ax.* values? Or should it be a full id_res response? * The spec says that the RP may include transaction information in the update_url to link the update to a particular identity URL. I guess this only makes sense if we aren't sending a full id_res response, since in that case the identity URL would be included. * How does the RP verify that posts to its update_url came from the OP and not some other party who got hold of/guessed update_url? If we are using an id_res response, then this'd be handled by the signature. If we sign the response, it brings up the second question: what do we use as an association handle? Can we use any available association handle, or would it be better to treat it as a dumb mode response and require the RP to do a check_authentication request to verify the data? If we aren't sending a full id_res response to the RP, it seems that the only security is in the secrecy of the update_url, which seems strange given the use of cryptographically signed messages in other parts of OpenID. * The spec seems to indicate that only the changed data should be sent in the update response. How would I notify the RP about the absence of an attribute? The closest I could come up with was to use count=0: openid.ax.type.foo=http://example.com/foo openid.ax.count.foo=0 It would be good to document the preferred way of doing this, since I could imagine an RP misinterpreting such a response (especially if the attribute is usually single valued). James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
