Re: Defining how OpenID should behave with fragments in the return_to url
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. 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. ___ 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
This looks similar in principle to the AJAX-ish (though not really AJAX at all) mode of OpenID that was in the early demos but no-one actually seems to have implemented in practice. The trick there was to do the OP dance in a hidden iframe and have the return_to page communicate with the outer page in much the same way as the popup does. However, the optimization of doing it with the fragment identifier is interesting. My first concern was backward compatibility, but it actually looks like we get back-compat by accident as long as openid_reciever.html is able to actually process the query string if it's present. Here's a strawman: * If the return_to URL ends with a # character, a supporting OP (or an OP that's doing this by accident) should make the return_to URL by appending the ? after the # and then adding the query string arguments as normal. * The non-fragment part of the URL MUST support having the arguments passed in the *real* query string. In this case, the fragment part should be ignored and is likely to be the empty string anyway. This allows OPs that don't work in the way you suggest to still work, albeit with worse UI performance due to the extra round-trip that will inevitably be generated. As far as I can tell, your openid_reciever.html can still be a static file in the query string case, becausee most existing web servers will accept and silently drop query string arguments on URLs that address static files, and the full URL should be available client side in docment.location to allow you to retrieve the query string. It'd be good to see how more existing OPs behave when presented with a return_to URL that ends with a #. Having MyOpenID fail is a show-stopper for the above approach IMHO, but hopefully they will fix their implementation if they are the only one broken. (I've quite deliberately said *ends with* rather than *contains* a # here, because that's a simpler thing to catch for folks who will need to fight their local URI-mangling library in order to implement this, which I assume applies to MySpace -- I presume that their correct behavior came for free with the .NET System.Net.Uri class.) Luke Shepard wrote: Hi- I've noticed an ambiguity with the way URLs are handled that exists in the current spec. I'm hoping we can resolve it for OpenID 2.1. When we move the OpenID transaction into a popup window, we need a way for the popup to communicate back with the parent. The way to do this is to set a return_to URL that, when loaded, reads the parameters and communicates with the parent window somehow. Here's a description of a technique: http://www.sociallipstick.com/2009/02/04/how-to-accept-openid-in-a-popup-without-leaving-the-page/ A simple way to do this is to have a simple receiver. The response will append query parameters: http://open.lukeshepard.com/openid_receiver.php?openid.ns=.. However, there is a small performance problem with this approach. The user will see a blank-looking popup for a moment while the server processes the OpenID arguments. An optimization is to put up a simple, cacheable static HTML file that chucks the OpenID params back to the parent frame. The parent can then provide some visual feedback to the user while it sends the OpenID parameters off for processing. This results in a snappier experience. If the static HTML file has no parameters and sends out long-lived cache headers, then the response won't even trigger a server load, and the whole process can appear faster to the user. In this case, the response would look like this: http://open.lukeshepard.com/openid_receiver.html#openid.ns=.. Note that the hash appears instead of a question-mark. That tells the browser that it doesn't need to load an extra file, and it can save perhaps a quarter or half second of latency for the user on average. Okay, so the point is that different OpenID providers currently interpret the hash differently. I think we should explicitly define a behavior that makes sense and accomodates the above suggestion. Here's how they currently behave. When given a return_to of http://open.lukeshepard.com/openid_receiver.html?query#hash Google: http://open.lukeshepard.com/openid_receiver.html?query#hash?openid.ns= Yahoo: http://open.lukeshepard.com/openid_receiver.html?query#hash?openid.ns= MySpaceID: http://open.lukeshepard.com/openid_receiver.html?queryopenid.ns=#hash MyOpenID: fails outright - invalid return_to By the URL spec, Myspace is technically correct and Google/Yahoo are wrong. But the correct way doesn't allow the performance optimization listed above. I'd like to see a way to accommodate the hash url. 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
Re: Request for consideration of AX 2.0 Working Group Charter Proposal
Dick Hardt wrote: I'd prefer to narrow the scope of the WG and keep it focussed on a small number of goals. A separate WG on SREG would be preferred, but I think it is a disservice to the community to have two specs having such significant overlap. Choice in this case leads to confusion and reluctance to invest. The challenge is that those with an investment in SREG now have a propensity to see it continue on even though intellectually they can see the advantage of a unified spec. fwiw: I am in an off-site most of this week and won't be able to engage significantly until next week. I agree that having both is not ideal, but I also feel strongly that we need to have a good SREG 1.1 spec because in practice today there are lots of SREG implementations and it is important to be able to interoperate with them even if in the long term we'd like to move to AX. This is, incidentally, why I was previously proposing forming an SREG group whose task is *only* to fix the spec to reflect current practice. This should encourage SREG interop in the short term while new developments to AX will encourage a move to AX in the longer term. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Request for consideration of AX 2.0 Working Group Charter Proposal
Henrik Biering wrote: Agree! If the range of SReg attributes is expanded, however, I would suggest to add phone number (incl. quality as suggested for email) and possibly street+city address line(s). That would make it possible to fill in a somewhat larger part of typical registration forms. It might be good to apply the quality thing to all of the fields. One approach might be to add a verified argument that contains a list of names of fields that the OP has verified in some way. However, I think the SREG spec itself needs work done since the 1.1 draft (that was never published) has a bunch of problems. It might be better to do such work in a separate working group; I already have an updated 1.1 draft with some of the problems from the current 1.1 draft fixed that could potentially be used as a basis, though I'll need to dig it out since I'm not sure what I checked it in to. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID Authentication 2.0 Errata
Hi folks, It seems that we don't currently have any central place to document the issues with OpenID Authentication 2.0, so I started a wiki page for it: http://wiki.openid.net/OpenID-Authentication-2_0-Errata Currently it only has one issue, which is the one that I encountered today that inspired me to do this. The proposal to create Auth 2.1 mentioned that there are other errata that should be included in that spec, so adding those here ought to be useful. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Request for consideration of Working Group Charter Proposal
Allen Tom wrote: Hi Nat - I'm not quite sure what you mean by class. Nat previously talked about the idea of bundling several attributes together into a single namespace rather than assigning a URL to each individual scalar attributes. He referred to it as a class though you might instead want to think of it as a struct. As I recall (I can't find the original message right now) the propsal went something like: ns.blah=http://example.com/some-struct blah.field1=xyz blah.field2=abc blah.field3=123 This way the URL is only included once, making the overall message shorter. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Allen Tom wrote: For the time being, we prefer to require CKs for client applications (even if they can't be verified) mostly to make it easy for us to pull the plug on specific applications if they are discovered to be severely buggy or dangerous. We'd also like to require pre-registration of CKs so that we know who to contact about a particular app if we have any questions. If I make a dangerous app using the consumer key from a popular application, would you black list that key and inconvenience all of its users? (I doubt it.) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Completing the SREG 1.1 specification
Hi all, It recently became apparent that version 1.1 of the Simple Registration Extension (SREG), which updates the protocol to work as an OpenID Authentication 2.0 extension, was never finished and published. Furthermore, it has been noted that the latest draft contains ambiguities about how SREG is to be used in 1.1 vs. 2.0 messages, and that in some cases it does not describe how SREG is used by popular implementations today. I'd like to form a working group to get version 1.1 completed, with a focus on simply writing down what current implementations do to aid interoperability rather than making any changes. I have a draft of a more formal working group proposal prepared, but first I'd like to see who is interested in working on this. The minimum membership for an OpenID Foundation working group is five members. I anticipate that this group's work will be done relatively quickly, since we'd merely be documenting established practice. Please reply here if you'd be interested in joining this working group, and in particular whether you are willing to be listed as a proposer in the working group proposal. I have included below my current draft working group proposal. I welcome any comments on it. Thanks, Martin OpenID Authentication 2.0 was finalized this past December and since has started to see quite reasonable adoption. Many implementations of Authentication 2.0 have made use of the Simple Registration Extension that was popularized as an ad-hoc OpenID 1.1 extension. While SREG is compatible with and has been deployed using the more formal extension mechanism described in OpenID Authentication 2.0, a 2.0-compatible version of SREG was never published. A draft revised version is available [1], but it was never approved as a specification and contains some ambiguities about how SREG is used in 2.0 vs 1.1 messages. This proposal is to form a working group to finish and publish a version of SREG that is compatible with OpenID Authentication 2.0, describing how SREG is used in existing popular implementations. == Background information == Many implementors have extrapolated how SREG 1.0 can be used within the extension mechanism defined in OpenID Authentication 2.0, but this has actually never been documented in a specification. A draft of SREG 1.1 was produced[1], but it was not published and has been found to contain some ambiguities and deviations from established practice. == Working Group Name == OpenID Simple Registration Extension 1.1 == Purpose == To complete and publish the SREG 1.1 specification, documenting how SREG is used by popular implementations today. == Scope == The proposed work is as follows: * Update the SREG specification to describe how it can be used as an OpenID 2.0 extension as well as an OpenID 1.1 ad-hoc extension. * Update the SREG specification to correct any deviations between the specification and established implementation practice. Note that this charter does not include adding new features to Simple Registration; ideally, the specification produced by this working group will merely be documenting existing implementation practice, and will require no changes to existing implementations as far as possible. Where implementations differ, an approach will be chosen on the basis of number of deployments and on consensus within the working group. == Anticipated Contributions == * Feedback from library authors and other implementors about how they have adapted SREG 1.0 to work within OpenID 2.0's extension mechanism. * Specification text to achieve the the goals described in the above scope. == Proposed List of Specifications == * OpenID Simple Registration Extension 1.1 (SREG 1.1) == Anticipated audience or users of the work == Implementers of OpenID Providers and Relying Parties. == Language in which the WG will conduct business == English. == Method of work == Work will take place primarily on the working group mailing list, with the possibility of conference calls and face-to-face meetings if deemed necessary by the working group. == Basis for determining when the work of the WG is completed == Proposed changes will be evaluated on the basis of whether they increase or decrease consensus within the working group. The work will be completed once it is apparent that maximal consensus on the draft has been achieved, consistent with the purpose and scope. Proposers: * Martin Atkins, Six Apart ([EMAIL PROTECTED]) * David Recordon, Six Apart ([EMAIL PROTECTED]) * ... Initial Editors: * Martin Atkins, Six Apart ([EMAIL PROTECTED]) * David Recordon, Six Apart ([EMAIL PROTECTED]) [1]http://openid.net/specs/openid-simple-registration-extension-1_1-01.html ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/OAuth hybrid - discovery
Dirk Balfanz wrote: I'm not sure I understand what the commotion is about :-) OAuth discovery (when it is done), will answer the question: given the URL of a resource, where do I go to get access tokens for that resource. The question answered by the XRD element described in Section 5 is does this OpenID endpoint support the Hybrid protocol. These two questions are somewhat related, but clearly different. And, yes, the latter is not nearly as exciting as the former. What is a consumer intended to do with this information? Telling me that the OpenID provider also supports the OAuth hybrid protocol is not useful alone. It's not like I can just take any OAuth token in the world and feed it to this endpoint. More useful, I think, would be to have the OAuth discovery information *at the service endpoint* say that the OAuth authorization URL for this service is some-url, and the combined OpenID/OAuth endpoint for this service is some-other-url. The first part of this will presumably be catered for by OAuth discovery. The second part seems like it ought to be an extension to OAuth discovery, though I don't have a good answer for what exactly it'd look like on the wire. As currently speced, I'm not sure what problem that section is addressing or what value it provides. Perhaps for now it'd be better to take that part out of the Hybrid Protocol specification and defer that problem until it's clearer how OAuth discovery will work in general. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/OAuth hybrid - discovery
Dirk Balfanz wrote: We're defining an OpenID extension. Consumer will want to know whether or not a given endpoint speaks that extension. That's all it's doing - just like AX or PAPE have a section on discoverability. It also gives consumers a way to look for the combined OpenID/OAuth endpoint (assuming that one day we'll have these massive XRD documents advertising all sorts of things - OAuth request token endpoints, portable contact endpoints, etc.). I guess I'm assuming that the OAuth service saying use that OpenID provider for hybrid OpenID/OAuth implies that the OpenID Provider supports the extension. However, I guess the following flow could arise: * User does something that requires OAuth. * Consumer does OAuth Discovery (to be defined) and determines, amongst other things, the URL of the OpenID Provider that will do the combined OpenID/OAuth bit. * Consumer does discovery on the OpenID Provider and determines that it doesn't actually support the extension. * Consumer falls back on the non-combined flow, or just tells the user that the service provider is broken. While it's nice to fail early in this case, the consumer still needs to deal with a bunch of post-authorization failure cases: * Provider claimed to support the extension but didn't actually return anything. * Provider claimed to support the extension but the approved request token doesn't actually work for some reason. * Provider claimed to support the extension but it turns out it doesn't support this particular sort of request token. * ... In most cases, the implication from the OAuth discovery step will be enough and everything will work out. I'm not sure whether failing early in this one (unlikely) error case is worth the extra HTTP transaction(s) to find out whether the provider really supports the extension. It'd be more efficient to just send a request to the OpenID provider with the extension arguments and see if you get back a response. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Allen Tom wrote: Manger, James H wrote: Ideally, an app would attempt to access a protected resource at an SP and get: * A 401 Unauthenticated response from the SP; with * A “WWW-Authenticate: OAuth” header; with * A parameter providing the authorization URL; and * Another parameter with the OP URL (when OpenID/OAuth hybrid was supported). One problem with this approach is that many SPs like Yahoo and MySpace will require developers to register their site to get a Consumer Key. Given that the developer already has to manually get a CK, there might not that much value in defining a workflow for Consumers to discover the OAuth endpoints. As long as this is true it will be impossible for such SPs to expose non-proprietary protocols like PortableContacts, so either these SPs will need to find a way to work without pre-registration or we'll all have to accept that the open stack is impossible and go find something more productive to do. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposing an OpenID Authentication 2.1 Working Group
Here's the output from today's IIW session on this: 2.0 has been finalized bunch of implementations found lots of spec bugs also gone and done oauth and email addresses and other things. Can we support these in the core spec? - Making the spec more readable and fixing bugs (eratta) - Delegation - Error handling - Adding a security appendix - could be a separate document referred to by the spec - possibly produced by separate group - Who controls this security page? - Security committee could look after this. - or Allen at Yahoo! will be editing a security document - Clarifying XRI - Currently there's no firm message about whether RPs MUST support XRIs or not. - Need to clarify how exactly XRI should be used with OpenID. - Similar to the whitelist question. - Clarify if RPs can white or blacklist what OPs they accept, and vice-versa. - Discovery of type of identifiers an RP supports. - Clarifying IRI - Updating discovery. Possibly including the new-fangled XRD discovery. - Clarifying whether association over SSL must/can use diffie-hellman. - Discovery of support of checkid_immediate. Exploratory work: - Signature mechanisms. Looking at additionally supporting the mechanisms defined in OAuth so that they can be closer together. - Possibly deprecating the current signature mechanism. - Public keys? - Email-shaped identifiers for OpenID - Could be a separate working group? There was consensus that email-shaped identifiers would be worked on by a separate group and possibly rolled into 2.1 if it's done in time. - Smart/rich clients? - Could be in this WG unless it ends up being a big change in which case it could be its own WG. - There's another session about this. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] OpenID Extension to handle Emails Addresses?
David Fuelling wrote: I would even entertain the notion of the OpenID extension doing DNS lookup first, then EAUT, though I need to think more on the topic. Alternatively, maybe we make DNS optional. At this point I'll throw in my more recent post about why DNS must be supported and must be the primary mode, with others as fallback: http://www.apparently.me.uk/18285.html However, I wouldn't necessarily object to putting the *EAUT* information in the DNS rather than the OpenID information directly. The two things I care most about at this point are: * DNS must be consulted first, for the reasons I go into in that post. * In the case where an email address is the claimed_identifier, the OpenID request must have openid.identity set to mailto:theemailaddress, not the mapped HTTP identifer. (In other words, this is an extension to OpenID *Discovery*; the rest of the protocol is unchanged.) The finer points of how we get there don't bother me that much. Being able to optionally redirect email addresses to URLs just as we can currently redirect URLs to other URLs would be good and consistent with the OpenID model that exists today. Preserving the ability to do delegation would be good so that I can use email addresses in my vanity domain without running my own OP. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] OpenID Extension to handle Emails Addresses?
David Fuelling wrote: 1. The arguments about using DNS could apply to OpenID in general. However, OpenID doesn't do anything with DNS. Why is this? What were the compelling reasons to not use DNS with OpenID? Is there an FAQ page somewhere about that? I have only vague recollections on the topic. When you have an HTTP-based identifier, I think it makes sense to use HTTP to resolve it. So, just as with any other HTTP transaction, you: * As the DNS for the server that handles HTTP for the domain. (Which the A record in the domain has become the de-facto standard for, for better or worse. It'd be good if it were a SRV record, but whatever.) * You ask the HTTP server what's at the path given in the URL. * The response tells you the OpenID discovery information or, in the Yadis case, where to find the discovery information. Now, you could argue (and people have argued) that using the MX record to find the mail server and somehow asking the mail server for the discovery information would be sensible. However, I would argue that this is overloading the concept of mail exchanger -- we don't use the MX record to discover IMAP or POP3 services either -- and that realistically speaking asking people to alter their SMTP server software is a complete non-starter. You could also reasonably argue that my proposal of resolving [EMAIL PROTECTED] as mart.degeneration.co.uk is a layering violation, since the username part does not belong in the DNS. I wouldn't mind losing that if someone has an alternative proposal for making delegation work. (One such proposal would be to put EAUT endpoint information in the DNS, of course. I wouldn't object to that on principle.) 2. Do some of the larger email providers have an opinion on the mechanism used for Discovery in the email case? For instance, would Google/Yahoo/etc prefer that DNS be consulted first, or that some HTTP-based discovery be consulted first? Do they even care? While obviously I can't speak for these big providers, my assumption in all this is that big providers can do whatever they like, whether it be altering the root of their website or putting stuff in DNS. Certainly the DNS change requirement hasn't stopped Hotmail or GMail supporting SPF. I would of course be interested to hear from one of the big providers on this subject, since as far as I can tell they've been silent on it so far. However, I wouldn't necessarily object to putting the *EAUT* information in the DNS rather than the OpenID information directly. The two things I care most about at this point are: * DNS must be consulted first, for the reasons I go into in that post. * In the case where an email address is the claimed_identifier, the OpenID request must have openid.identity set to mailto:theemailaddress mailto:theemailaddress, not the mapped HTTP identifer. (In other words, this is an extension to OpenID *Discovery*; the rest of the protocol is unchanged.) What if the user actually wants their URL to be the claimed identifier? Would you be open to that? I still haven't quite followed why, in that case, the user wouldn't just enter the URL into the OpenID box at the RP. If the user knows what a URL is enough to know they want to use it as an identifier, I think they can manage to type it in without relying on a layer of indirection to achieve that. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] OpenID Extension to handle Emails Addresses?
Hallam-Baker, Phillip wrote: Well we already have a specification for that, it is the core architecture of the Internet: DNS. We use the DNS SRV record for service discovery. It is what it is designed for. It provides for fault tolerance, load balancing, fall over just like an email MX record. Thanks for another voice in favor of DNS. I was beginning to feel like the only one on this side of the fence. :) The simplest discovery mechanism then is: _openid.example.com SRV 1 100 80 openid.example.com I did consider SRV, but the return value from OpenID discovery is not a hostname, it's a structure like this: * Endpoint URL * Final claimed identifier (after following redirects) * OP-local identifier (or delegate in 1.1 terminology) * OpenID version (either 1.1 or 2.0, currently) Some of these we can infer. For example, in my DNS-based proposal I just assumed that all email-based identifiers would use OpenID 2.0, because a provider's going to have to change their implementation anyway so they might as well upgrade to 2.0 while they're at it if they don't support it already. I went with a TXT record with a custom serialization, despite it being technically incorrect, both so that the information required for the above structure could be represented and also so that it can be deployed on DNS providers that only allow A, CNAME, MX and TXT records to be configured. The latter is important for the delegation case, as the main audience for delegation is people with vanity domains. OK so now lets think about market building a bit. Lets try to embrace and extend the competition. In my view the value of OpenID is not so much the protocol as the idea of an interoperable identifier. So lets try to capture the SAML and WS-* worlds as well. We can do this with a policy declaration: _openid.example.com TXT v=openid openid saml _openid.example.com SRV 1 100 80 openid1.example.com _openid.example.com SRV 1 100 80 openid2.example.com _saml.example.com SRV 1 100 80 saml1.example.com _saml.example.com SRV 1 100 80 saml2.example.com And I infer from this that you're not adverse to the idea of encoding custom formats in TXT records, so hopefully you'll appreciate my approach. However, if you've got an alternative proposal that's more DNS-pure I'd be happy to hear it. I don't claim to be a DNS expert. However, it'd take a very convincing argument for me to get behind anything that requires something other than A, CNAME, MX and TXT records though, for the reasons stated above. (In case you haven't seen it, my current strawman proposal is here: http://www.apparently.me.uk/18285.html ) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: This is user's URI for Assertion Quality Extension
SitG Admin wrote: http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html I'd like to see the 4th draft of this include a URI level authentication property. I'd like to know whether the OP is asserting that the user is a member of Site, is this specific user *at* Site, or is a member of Site and we've generated this unique Directed Identity for them that won't reveal their userID at Site but will allow you, the RP, to distinguish between this anonymous Site user and other anonymous Site users. What's the use-case? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Backporting the 2.0 extension mechanism to 1.1
Nat Sakimura wrote: Actially, that interpretation is not right. In draft 3, we have made it clear. Draft 3 now seems to say: For the purposes of this document and when constructing OpenID 1.1 and 2.0 messages, the extension namespace alias SHALL be pape. Which now seems to require that pape must always be the namespace alias, in both 1.1 and 2.0. I don't understand what the intention of this sentence is if this is not a correct interpretation. However, my original message was not really a comment on the PAPE spec so much as a comment on the general lack of an extensibility mechanism in OpenID 1.1. The PAPE spec (the sentence I quoted above notwithstanding) currently seems to assume that the 2.0 namespace mechanism is available in 1.1, but as far as I'm aware there has never been a published specification allowing this. (please correct me if I'm wrong.) 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. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID 2.0 Specifications
Arshad Khan wrote: Hello, Can I please have OpenID 2.0 specifications? Can I also request link to software codes for sever and consumer? http://openid.net/specs/openid-authentication-2_0.html http://openidenabled.com/ http://code.google.com/p/dotnetopenid/ http://code.google.com/p/openid4java/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID 2.0 Specifications
Arshad Khan wrote: Hi Martin, Thanks for this. Is it possible to get the specification in word or pdf format? I don't think this is published online, but you should be able to load the HTML version into Word and save it as .doc if necessary. Also, I am not clear if I need to read and incorporate the following specifications in addition to OpenID 2.0 Authentication document - OpenID Attribute Exchange 1.0 – Final - OpenID Simple Registration Extension 1.0 These are optional extensions to OpenID and so you only need to read them if they are important for your application. - OpenID Authentication 1.1 This is the older version of OpenID Authentication; a compatibility mode for this is documented in the 2.0 spec and supported in the 2.0 libraries. Sorry, I am new to this. Also, can you please advise if PHP version of code is available? http://openidenabled.com/ has a PHP library as well as Python and Ruby libraries. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Backporting the 2.0 extension mechanism to 1.1
I notice that, like sreg, the pape extension is supporting 1.1 by simply hard-coding the pape prefix on its arguments. This approach is troublesome for the Net::OpenID::Consumer perl library because it deals only in extension URIs, and supports sreg in 1.1 as a special case. In order to preserve the abstraction the library would need to be altered each time an extension adds a new hard-coded prefix in this way, which is not ideal. Therefore I'd like to propose that for PAPE and all future specifications the 2.0 extension mechanism simply be allowed in 1.1. I don't think it needs any modification in order to work for 1.1, except that for legacy reasons SREG should continue to have the sreg prefix reserved when in 1.1 mode. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Backporting the 2.0 extension mechanism to 1.1
Johnny Bufu wrote: 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 In that referenced section it says: For the purposes of this document *and when constructing OpenID 1.1 messages*, the extension namespace alias SHALL be pape. (emphasis mine) I understand that to mean that when making a 1.1 request the alias must be pape. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Responding to a 2.0 request with a 1.1 response
(sorry for responding to myself.) Martin Atkins wrote: Another similar and perhaps more likely case is when a user does 2.0-style delegation to a clavid.com identifier, omitting the 1.1-style delegation. Net::OpenID::Consumer with 1.1 compatibility enabled fails in this case because the 1.1 version of the OP does not appear in the list of discovered providers. In fact, having read my logs in a little more detail, I see that this mid-flow switch actually breaks delegation altogether in Net::OpenID, because in the 1.1 case we put the user's identifier in an oic.identity argument inside the return URL, but in the 2.0 case we use the standard openid.claimed_id argument instead. For clavid.com, we send out the 2.0 request with openid.claimed_id, but when they send back their 1.1 response openid.claimed_id is not available and their server doesn't know (and shouldn't know) about our non-standard oic.identity argument. Having noticed this I'm pretty convinced that switching versions mid-exchange is harmful and should be explicitly forbidden by the specification; I don't think there's really any way that a mid-exchange switch could be specified that didn't suffer from this flaw. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Using email address as OpenID identifier
Paul E. Jones wrote: Perhaps it is important to say, though, that I do not think it requires the e-mail providers to get on board with this (in my view) simpler notation. I could use an ID like [EMAIL PROTECTED] and that should work, if myopenid.com would publish the appropriate NAPTR record. I could also insert NAPTR records into the packetizer.com DNS server that would allow me to use my email address, but point at my preferred OpenID provider. In short, just because the [EMAIL PROTECTED] syntax is used does not mean that it necessarily an e-mail address: it could be, but more importantly, it just follows that familiar format documented in RFC 822. Funnily enough, I've always percieved the fact that syntactically-valid but non-existant email addresses are being used as identifiers as a problem rather than a benefit: * It creates confusion for users when something looks like an email address but it doesn't behave as one. I've seen this sort of confusion with Jabber servers, where users get confused that their Jabber ID and email address are not the same, especially when Jabber clients say For example, [EMAIL PROTECTED] under the Jabber ID field. * If not all email-shaped OpenID identifiers are actually working mailboxes, it's likely to lead to a distressing user experience where the user is first asked to enter their OpenID identifier -- that is, their email address -- and then they're asked to enter and verify their email address. At this point, I expect users to at best say Stupid computer! Remember what I've told you! and at worst get confused and think that the OpenID identifier they entered was not correct. * As has often been raised in both the OpenID-with-email and in the Jabber circles, many people are reluctant to give up their email addresses to the public eye for fear of spam. Note that Yahoo.com will, by default, use a big opaque string as an identifier rather than the user's Yahoo! account name for this very reason. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Using email address as OpenID identifier
Paul E. Jones wrote: I’ll give you that one: that’s certainly easier. But, does not cause some confusion? After all, one’s identity is not yahoo.com, but that is the identity provider. Perhaps the prompts around the Internet ought to Say “OpenID Provider:” instead? :-) I propose that the caption be Whatever your OpenID provider told you to enter: . (I joke, of course. Mostly.) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: handling of url redirection
Jonathan Daugherty wrote: This is what I was getting at- it'd be good to give users an identical experience when they sign into various OpenID-enabled apps. Just to be clear, this is not an interop issue. This is a matter of drawing the line between what is sane and what is not. For pathological cases (e.g., excessive redirects) there isn't a sane interop behavior, only a sane fallback behavior. +1 for _recommending_ a maximum number of redirects in the spec so implementors have some idea of what is sane. I think any more than 10 is pathological. It may be worth noting that some implementations have both a limit on the actual number of redirects and on the total time for the request, including all redirects. In otherwords, unreasonable redirects can be measured by the time taken to do them rather than their actual number. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Integration with Enterprise Directory Services
Drummond Reed wrote: Yes, Marty Schleiff at Boeing is working on an RFC for how to represent XRIs in an LDAP directory for that very reason -- to establish standard OIDs for this attribute. LDAP already has a URI attribute type, but downcasting an XRI into a URI just to squeeze it into that attribute type loses the semantics that the XRI is an abstract identifier for the resource. So Boeing wants to establish OIDs for primary-xri (value of the canonical XRI) and alt-xri (value of any other XRI synonym). This is perhaps a bit of a tangent, but what are the disadvantages to representing XRI as a URI? It seems to me that having two completely orthogonal sorts of identifier rather than having one be a subset of the other just makes things needlessly complex. What makes you consider XRI to be an abstract identifier but a URI not to be? The whole thing of just starting with an equals sign is very cute, but surely that's just a shorthand to avoid writing xri:// in contexts where it's unambiguous, much like people routinely write things like www.google.com when an http: URI is expected. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: SREG 1.1 Request parameters
Enis Soztutar wrote: 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. This distinction is made to avoid the following flow, which isn't very user-friendly: 1. RP sends user to OP with a request for email address. 2. OP asks user whether or not to send email address. 3. User elects not to send email address. 4. RP then says We can't let you register without an email address. Type one in here. 5. User elects to supply an email address after all, but now has no assistance from the OP to complete this field. By having the optional/required distinction, in step two the OP can say something like The RP may not allow you to log in without this information. This means that the user can make the decision in step 3 with the knowledge that it probably won't succeed, or he can make the decision in step 5 a few steps earlier and get assistance from the OP to enter the email address. It's only a very subtle distinction, but it is important so that the OP can explain the situation to the user at the right point in the transaction. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Inline Authentication Extension 1.0 Draft 1
John Ehn wrote: Martin, Thanks for the response! I'm looking at those specs now, and I really like the flow of the HTTP Authentication spec, because it looks like it's solving the problem of passing the OpenID Identifier to the RP in an automated way, which is really cool. Looks like it needs to be fleshed out in some parts, though. Both of these specs need work. What you see up there on the wiki is really just a brain dump wanting to be turned into a spec. I've not really had much time to work on them, though. As for the Signature Request protocol, I'm not quite sure what it does yet, but I'll let you know my opinion once I've digested it. The HTTP Authentication spec has a part in it where it says the client must get a signature from somewhere. When I originally specced it my only answer here was that non-human agents can act as their own OP and therefore they could just compute the signature themselves, but realising that this protocol had applications for humans authenticating to services inside specialised rich clients (Last.fm's Audioscrobbler API, for example, or JOSM for OpenStreetMap) I added Signature Request Protocol as a standard mechanism for rich client RPs to obtain a signature from the user's OP. As I think it notes somewhere in the copy, I'm imagining in the ideal case a desktop service or at least a shared library that does the SRP bit on behalf of all of the user's applications, so that each application does not need to be given the user's OP credentials. It was my hope that it could theoretically be integrated with systems like Apple's Keychain. However, SRP is still very rough-and-ready and still has lots of outstanding issues. I think Inline Authentication might have the answer to some of these issues. Cheers, Martin ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Do We Agree on the Problem We're Trying to Solve?
Josh Hoyt wrote: On 6/11/07, Martin Atkins [EMAIL PROTECTED] wrote: Presumably the recommendation would be to have several identifiers attached to a single account just as is recommended today. I would point most of my identifiers at one canonical identifier but retain one or more special backup identifiers that do not point at my persistent identifier so that I can reclaim my account if my persistent identifier goes away. Why bother with a canonical identifier if you're going to need multiple identifiers attached to an account anyway? Why bother using OpenID if you need to have multiple identifiers attached to your account anyway? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: The CanonicalID Approach
Josh Hoyt wrote: On 6/9/07, Martin Atkins [EMAIL PROTECTED] wrote: I'm assuming that the RP authenticates http://inconvenient.example.com/001, not http://impersonation.example.com/mart. Just as with delegation, if I can successfully authenticate as the persistent identifier and the non-persistent identifier points at the persistent one, we can assume that http://impersonation.example.com/mart is me as well. If you agree that: 1. In order to authenticate as the persistent identifier, discovery must be done on the persistent identifier 2. In order to determine that the non-persistent identifier points at the persistent one, discovery must be done on the non-persistent identifier. Right you are. The detail I was missing was that if, as in delegation, the non-persistent identifier is trusted to nominate a server endpoint for authentication, it becomes possible to lie about the server endpoint and claim any identifier. But can we guarantee that it is always exactly two discovery steps? If my CanonicalID points at an identifier which itself also has a CanonocalID, do we follow it recursively? I can't really think of any security flaws as a result of only following one level of CanonicalID, but it may be counter-intuitive for implementors. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: The CanonicalID Approach
Josh Hoyt wrote: On 6/8/07, Martin Atkins [EMAIL PROTECTED] wrote: I figure that you could potentially use the same mechanism as delegation to avoid the extra discovery iteration. The problem, as with delegation, is that you need to duplicate the endpoint URL in the source identifier's XRDS document. The canonical identifier must also support OpenID, which I believe is something they were trying to avoid. I'm assuming that by saying it's like delegation, you mean that the canonical identifier is discovered from the entered identifier, and sent to the server, but discovery is never done. Let's say that you use http://mart-atkins.com/; as your identifier, with a canonical id of http://inconvenient.example.com/001; I can set up a URL http://impersonation.example.com/mart; that points to an OpenID provider that I control, and give it the same canonical ID, http://inconvenient.example.com/001;. Unless we make sure that the canonical ID is intended to be used with this OpenID server, I can sign in to your account anywhere, since the canonical ID is used as the database key. Were you thinking of a different mechanism? I'm assuming that the RP authenticates http://inconvenient.example.com/001, not http://impersonation.example.com/mart. Just as with delegation, if I can successfully authenticate as the persistent identifier and the non-persistent identifier points at the persistent one, we can assume that http://impersonation.example.com/mart is me as well. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: The CanonicalID Approach
Josh Hoyt wrote: On 6/7/07, Recordon, David [EMAIL PROTECTED] wrote: What I'd like to markup is that my three reassignable identifiers so that they all use my LiveJournal userid URL as the persistent identifier. It should be noted that also marking them as synonyms to each other follows the same sort of process using the Ref/ tag in my various XRDS files. -1 on requiring a whole extra round of discovery for every sign in. If you can come up with a way to verify that (a) the identifier in question points to the canonical ID and (b) the canonical ID has the appropriate information in it without doing twice the discovery, I'd like to hear it. I figure that you could potentially use the same mechanism as delegation to avoid the extra discovery iteration. The problem, as with delegation, is that you need to duplicate the endpoint URL in the source identifier's XRDS document. The canonical identifier must also support OpenID, which I believe is something they were trying to avoid. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Generalized solution to OpenID recycling (was RE: The WordPress User Problem)
=drummond.reed wrote: As Martin has pointed out, the purpose of the CanonicalID element in XRDS is to support reassignable-to-persistent identifier mapping. Although this is a native function of XRI resolution (because XRI architecture was explicitly designed to address the reassignable-to-persistent synonym mapping problem and thus has explicit syntax for reassignable and persistent identifiers), there is nothing to prevent CanonicalID mapping from being done with URLs. Discussion on this thread so far has only entertained using this mechanism to handle reassignable-URL to persistent-XRI mapping, however there's nothing to prevent it being used for reassignable-URL to persistent-URL mapping, or even reassignable-URL to persistent-URN mapping (as long as the URN is resolveable, such as a Handle ID). Everything is already in place in XRDS architecture except the Canonical ID verification rules. The OASIS XRI TC has already published the reassignable-XRI-to-persistent-XRI Canonical ID verification rules in the first editor's draft of XRI Resolution 2.0 Working Draft 11 (a more detailed explanation of those rules will be in the second editor's draft due out tomorrow). Per Martin's suggestion, in the second editor's draft will also add the Canonical ID verification rules for reassignable-URL-to-persistent-XRI mapping. 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. I think that URL-to-URL is more useful in the short term, because (unless something's changed since we last talked) you can't currently get an i-number without purchasing an i-name. This does, however, raise a transitional issue: as soon as providers start publishing CanonicalID, all of the existing accounts are effectively broken because the primary key is being changed.[1] If LiveJournal were to suddenly start publishing in the XRDS for http://frank.livejournal.com/ that the CanonicalID were http://www.livejournal.com/u/3449 (for example) frank would lose his account on any site he had already been using. For this to work out, RPs would have to change to retaining a list of synonyms rather than simply keying off the CanonicalID, but then that defeats the object of creating the ability for identifiers to be recycled. The only solution which springs immediately to mind is to get all of the big OP players to implement this and then have the burden be on RPs to handle the migration from the old display identifiers to the new CanonicalIDs as they transition from 1.1 to 2.0. This only works if things are changed in a particular order, though. I'm attracted to the cleanliness of using the same CanonicalID mechanism for both URLs and XRIs and any combination of the pair, but unless the above can be resolved I don't think it's workable. [1] This issue exists for the fragment approach too, but with the obvious solution that you simply don't starting appending a fragment until an identifier enters its second generation. This solution is not appropriate for CanonicalID because it has more broad semantics than simply identifying the generation number of the identifier. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Auth 2.0 Extensions: Namespace Prefixes
Johnny Bufu wrote: 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. For what it's worth, I'm no longer in favour of my own proposal. :) It was ill-thought-out and does not solve the problem I set out to solve. My intention was to create a situation where the question of Is extension x used in this request requires a single dictionary lookup, which the extensions field does not solve. Since that is not really workable without moving away from the use of URIs to identify extensions, I'm happy to accept this small wart for the sake of keeping things sane and simple. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification
Claus Färber wrote: Marius Scurtescu schrieb: The new attribute values are needed in order to signal an OpenID 2 provider. Why is this necessary? Is OpenID 2 incompatible? In other words, what happens if an OpenID 2 Relying Party tries to talk to an OpenID 1.x Provider? If the OpenID 1.x Provider just ignores additional message fields (i.e. treats them like an unknown extension), then no new rel values are needed. If this is not the case, maybe the OID 2 spec can be changed to make it possible. One incompatibility that springs to mind is that it is permissable to talk to a 2.0 OP via a POST request with the arguments in the entity body, while a 1.1 will likely barf on this since 1.1 only allowed for GET requests with the arguments in the query string. A 2.0 RP that uses a GET request and uses extension prefixes that match the ad-hoc field names used for the 1.1 extensions could, in theory, talk to a 1.1 OP without any problems. That is, unless I've missed something. :) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Specifying identifier recycling
Johnny Bufu wrote: 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.) Indeed, CanonicalID verification would be necessary, but it's already necessary if you want to accept XRI-based logins anyway. Last time we were talking about this CanonicalID verification for XRI was not yet specified. Is it now specified somewhere? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Specifying identifier recycling
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. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Auth 2.0 Extensions: Namespace Prefixes
As currently defined, an extension has a global namespace URI as well as a request-local alias/prefix. For an extension with the namespace http://example.com/blah that has a field foo, the following fields are to be sent: openid.ns.blah=http://example.com/blah openid.blah.foo=bar It seems to me that the only way to discover the extension namespaces used in a particular message is to iterate over all keys looking for openid.ns.(\w+) and then see if the value matches. This seems ugly since usually webapps deal with such arguments as a dictionary structure, and use dictionary dicipline while interrogating the values. If we added an extra field: openid.extensions=blah,sreg,ax then the extensions used in a message would be accessible by splitting that field on its commas and then accessing openid.ns.whatever for each one. It's still not ideal, of course; it'd be better if the full namespace URI were included in the key part of a (key,value) pair, but many frameworks[1] can't deal with wacky punctuation characters in the key. [1] I'm looking at you, PHP. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Authentication Protocols for Non-browser Apps
Gabe Wachob wrote: Hi Mart- I'm trying to figure out if what you are proposing covers the same use case that I discussed at http://openid.net/pipermail/general/2007-March/002005.html I'm not clear actually what you are trying to do with HTTP Authentication, and it may be completely unrelated to my use case, or it could be squarely in the same place. In your proposal, is there any interaction with a user? If so, when? All I see is that the caller sends a signature with the authenticated request. Is this implying that the caller performs some function with the OP to generate this signature? How does this happen? Can I use an existing OP with my URL or XRI to generate this signature? If so, how? The HTTP authentication bit does not specify how the signature is obtained. This is because when some application service is authenticating as itself it can maintain its own associations and generate its own signature without the indirection. Where the Signature Request Protocol comes in is making this protocol applicable to user authentication as well. Unfortunately, it *does* require the OP to support an additional protocol mode where the user is authenticated using HTTP authentication (or some other machine-interpretable authentication) rather than HTML forms and redirections. The flow I'm expecting for the latter is, to take the Last.fm client[1] as an example, that the user will enter an identifier URI into the preferences dialog where currently a username/password is entered. When the client-side app needs to make a request, it'll first do an unauthenticated request and see what HTTP authentication mechanisms are supported, and then prompt the user for appropriate credentials. In the future, I'm hoping that the signature-fetching steps will be replaced with call into an installed system service which will prompt the user to release a signature, thus avoiding the need for the user to give up the credentials to the client app and allowing the user to approve each application is is often done with a desktop firewall. [1] http://www.last.fm/tools/downloads/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: password-free login without SSL and OP reliance (an anti-phishing solution)
Douglas Otis wrote: For clarity, OpenID Authentication 2.0 - Draft 11 4.1.1. Key-Value Form Encoding should change to something like Keyword-Value Form Encoding. Avoid using the word key to mean field or label. This will cause confusion. While I believe that key-value pairs is a common enough term that confusion is unlikely by any knowledgeable developer, I suggest that if it be changed it be changed to name-value form encoding, since I think this is more commonly used than keyword-value. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)
Johnny Bufu wrote: 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 a purely selfish point of view, I'm happy for this discussion to take part on the specs list just so I don't have to join and configure YET ANOTHER MAILING LIST(tm). :) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)
Johnny Bufu wrote: 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). I tend to think it's a good idea to modularize specifications in the same way as you'd probably modularize the implementation. This is why[1] I was pushing for separate Auth / service discovery stuff: the service discovery stuff is obviously useful for things other than auth, and there are *already* separate libraries for it (Service::Yadis and friends), so it makes sense for it to be given as a separate specification. On the other hand, I also think it's a good idea not to modularize too early: until there's some implementation experience, it's hard to say with certainty what parts make sense as distinct modules. I'm not that familiar with the AX stuff yet, but my gut feeling is that it'd be a good idea for someone to make an experimental implementation to get some implementation experience and then it'll probably be a lot more clear where the articulation points are that make spec modularization worthwhile. There's little point in debating it at this early stage, in my opinion. - [1] One of the reasons, anyway. The other reason was to reach a situation where the OpenID Authentication specification can largely reference only other specifications under the OpenID umberella, which means bringing the Yadis tech into OpenID land (which it basically already is, despite the distinct brand) and defining a subset of the XRDS schema to avoid referencing the entirety of XRI Resolution 2.0, which contains lots of stuff that is not necessary for OpenID and related tech. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
[I initially sent this to Chris directly, because he sent his message to me directly. Then I noticed he'd also replied on the list. Hopefully he'll see this before my private reply and we can avoid another go-around of duplicate messages!] Chris Drake wrote: MA For some things it's legitimate: they need to store your name because MA otherwise they'd need to talk to your OP (via you!) every time they MA render a page containing something attributed to you. OK - yes - I concede that some data age complexity does probably creep back in if RPs choose to deny users the opportunity to audit the use of user information. (If I've got a choice between 2 RPs, and RP1 renders pages with my name in it, without giving me control over that, while RP2 makes repeated calls to my OP every time it occurs: I'll always choose to use RP2 - because it's the only one of the 2 options that's user centric, and gives me the ability to control the use of my information. Yes - this could be a tough drain on RP and OP resources. Tough. You can't just wash your hands of this problem because it doesn't suit your rather bizarre idea about how the world should be. Sites need to be able to attribute contributions to users, and in order to do that they need the user's name. A forum site cannot retrieve the name of every user that took part in a topic from their respective OPs while rendering the topic page. Tough is not an acceptable answer: rendering a topic page is a legitimate function of a forum site and attributing each message is necessary. MA they need to store your name because MA otherwise they'd need to talk to your OP (via you!) via you! is not a correct statement. This is a server-to-server topic: we're discussing a data flow that is by your explicit prior permission, but that takes place when you are not necessarily present. Right. Some people had been talking about not allowing this out-of-band information fetching. Even without the need for the user to be present, it's still prohibitively expensive. MA For other things it's more dubious than that, but the fact that it MA is technically possible means that at least some RP's will do it. MA I think it'd be a mistake to write the spec under the assumption MA that they won't unless we're going to include something that MA prevents it. I do not follow your logic. It looks like you're saying there is an opportunity for some RP's to act badly, therefore we should not even try to code user-protection into the protocol On the contrary, I'm saying that if you don't want RPs to retain user information then you should include some TECHNICAL MEASURE that prevents them from doing so. I think an acceptable compromise is to instead give users a way to express their wishes about how the data can be retained in the form of a update this every n months/weeks/years/whatever or a hard expires on this date-type rule. This way you acknowledge that there are indeed applications that need to retain user information for certain purposes and allow the user to have some control over this process. You could also put in a don't retain this at all flag, which in my forum case would probably cause the forum to just identify you by your raw OpenID identifier and have done with it. By all means - include preventative code (and for some kinds of attributes, digital time-stamped and signed assersions about the attributes solve these problems). But I think it's a far bigger mistake to completely leave out a server-to-server channel altogether. I have nothing against the server-to-server channel. In fact, the server-to-server channel is a prerequisite for the update this every n months thing because otherwise the RP would have no way to do that update. When a rogue RP violates your trust and caches data without your permission, that's bad. So a way is is needed for: * A trustworthy RP to indicate how long it would like to retain certain items of data * A user to indicate how long he would like certain items of data retained for, or how often the RP should try to refresh that data. * A way for the user to prevent further updates of a particular attribute by a particular RP after a certain date. The first and second points above would, I think, be helped by defining some reasonable defaults for each attribute type, just so that the average user doesn't necessarily have to spend ages entering update frequencies and expiry dates every time some attributes are requested for the first time. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
Chris Drake wrote: Hi Martin, Yes - sorry - I accidentally hit reply instead of reply all. I later did re-post to the list though. For the benefit of the list, your reply is at the end here. Re-reading my reply, I think my wording sounded pretty strong, and I might not have made it clear that I'm not pushing for 100% of data to live at the OP: rather - I want to give the user a choice in the matter (that is - after all - the entire spirit of user-centric). I want users to have the *option* to decide whether to sign up to RP#A or RP#B, and be able to base their decision upon the data-handling and protection practices of the RP. Some RP's will want to store everything just like they do today. Some will want to embrace user centricity and give their customers full control, and most will probably tread a line somewhere inbetween. As long as we build something that supports all this, then we can leave it up to the normal market forces to steer the Identity future the way they want - with the key issue (for us) being that OpenID has the chance to persist in this future. Right now - OpenID is right at the bottom of the pile, being almost the worst Identity 2.0 protocol currently on the market. IMHO - this is a problem that's easily fixed. I believe we are aiming for much the same thing, though perhaps I'm coming at it from a different perspective. My original message was proposing support for expressing the user's desires for how long particular data items should be retained without refreshing them, which seems to fit into your world view as described above. I was simply suggesting that expecting RPs to retain *no information at all* is unrealistic, and so we should provide a mechanism for users to express how they would like their data to be used rather than just assuming that RPs will retain nothing. I wrote: Yes - this could be a tough drain on RP and OP resources. Tough. You wrote: MA You can't just wash your hands of this problem because it doesn't suit MA your rather bizarre idea about how the world should be. Sites need to be I contest that I *am* allowed to wash my hands at this point, because it is absolutely my problem: I operate an OP, and I'm involved in helping RPs accomplish Web 2.0 goals. I'm smack in the middle of all the consequences that flow from allowing users to control their own data howsoever they wish. I further contest that the idea of me being in control of my own information about me is not bizarre. It might not be how anything on the web works today - true - but I'm pretty confident this is something most people do, or will, want. Imagine you're at the newsagent buying a magazine. You hand over your credit card, and the shopkeeper says No problem - I'm happy to sell you your goods, but I need you to first agree to let me make a photocopy of your credit card, grab you name and email address, and keep it in all on our files for the next 10 years. Oh - and we'll need to be sending you the occasional marketing message from time to time over those 10 years as well. Now *that* is something that almost everyone will agree is bizarre. Note that I was focusing on the example you gave of a user's name, rather than of a user's credit card information. Different data deserves different treatment. I'll wholeheartedly agree that it's undesirable for a vendor to retain credit card information — they currently do so largely because there's nowhere else that it can be centrally stored and retrieved, but AX changes that — but other data such as a user's name are another matter. When I meet people, I routinely tell them my name. I don't expect them to immediately forget my name after our conversation — in fact, like most people, I'm probably subconsciously offended when people *don't* remember my name. I control people's access to that data by simply not telling them in the first place. I think that what we can take from this misunderstanding is that not only do different *attributes* have different usage expectations, but also different *situations* have different usage expectations: you're largely focusing on businesses and financial transactions, while I'm largely focusing on social situations such as forums, weblogs and social networking. This may be caused by a difference in our backgrounds or interests, but whatever the reason it does show that different situations call for different behavior, and is yet another reason why users should be able to express their desires on a case-by-case basis if it is important for them to do so. I like Vinay's subsequent suggestion that this somehow be made legally binding, although I'm not sufficiently knowledgable about the relevant law to know how that can be put into practice. [snip] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Promoting OpenID
McGovern, James F (HTSC, IT) wrote: Is anyone here working with vendors in the ERP, CRM, ECM, BPM or VRM spaces such that user-centric identity is built into their product? Mm tasty acronym soup! ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: SREG namespace URI rollback
Recordon, David wrote: I see there being a gap between SREG and AX with nothing bridging it. IMHO, AX takes too large of a step for people to use it if they just want a few more SREG fields. I think we need something which does nothing more than provide a way to extend SREG and that will solve the majority of problems today. Presumably once we're on OpenID 2, those that need extensions can just define their own extension namespace. They can follow the conventions of SREG if they want, though of course they can really do whatever they like as long as it can be represented in an OpenID 2 request. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
Chris Drake wrote: Hi Martin, You wrote MA The age of the information needs to be taken into account here. When the information (rightly) lives at the OP instead of the RP, none of that age complexity exists. It's *my* name. It's *my* credit card. If any RP wants this info, make them come to me (my OP) and get it. Let me say no. Let me know each time they ask. But most importantly, let me (my OP) provide the correct, updated info each time the RP wants it. I think you're kidding yourself if you believe that RP's won't cache the information they obtain. For some things it's legitimate: they need to store your name because otherwise they'd need to talk to your OP (via you!) every time they render a page containing something attributed to you. For other things it's more dubious than that, but the fact that it is technically possible means that at least some RP's will do it. I think it'd be a mistake to write the spec under the assumption that they won't unless we're going to include something that prevents it. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
HTTP Authentication Bindings for two-party OpenID Authentication
OpenID is currently only useful for three-party authentication where an end user (usually a human) is logging in to an RP with the help of an OpenID provider. However, we do not have a solution for a software agent representing itself. Software agents don't need an OpenID Provider in the same sense as a human does because they can fill the role of the OpenID Provider themselves. A long time ago I posted a proposal where HTTP Authentication is used as a transport for this sort of two-party OpenID Authentication: http://www.lifewiki.net/openid/OpenIDHTTPAuth As noted on the wiki page, this is not intended to help non-human agents log into traditional RPs (e.g. websites) but rather to be used with specialized protocols where one non-human agent needs to talk directly to an RP without a user present. The main problem people had with this at the time was the use of dumb mode, due to its vulnerability to MitM-type attacks. I would like a two-party authentication protocol like this for use in several machine-to-machine protocols I'm designing[1], but I'm reluctant to reference it right now while I know people (quite rightly!) have reservations about the security of it. The obvious approach is to specify a way to do DH associations over an HTTP authentication protocol. However, it's not clear to me how to do a multi-stage authentication handshake efficiently over HTTP auth, since HTTP authentication is based around sending the request, getting back a 401 Unauthorized response and then repeating the request in its entirety with appropriate authentication credentials. I'm told that the Negotiate authentication scheme for Kerberos does this by retaining the request as state on the server and having the intermediate requests and responses contain no body, but this doesn't really seem in the spirit of HTTP. I'd be interested in any insight that others may have to offer. - [1] My hope is that dependent protocols will be able to use interchangably either three-party request authentication via OpenID Exchange[2] or two-party authentication via this specification, so that protocols like Send A Message[3] will be able to work in both modes. [2] http://openid.net/wiki/index.php/OpenID_Exchange_1.0 [3] http://openid.net/wiki/index.php/Send_A_Message_Protocol ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
XRD-based Service Discovery - Draft 1
In respose to the discussion recently about modularizing the discovery part of OpenID Authentication 2.0, I've put together a possible first draft of a specification for doing service discovery using XRDS. This document is really just the XRDS-related parts of Yadis but refactored slightly. In particular: * XRI Resolution 2.0 is no longer required reading for implementors. Instead, it defines its own proper subset of XRDS/XRD which is completely defined within this document. * The various sentences referring to authentication services and specifically to OpenID, LID, etc. have been rewritten or removed. My intention here is that the remaining parts of Yadis that are not included in this new specification will become XRDS Discovery for HTTP and HTTPS URLs. It'd be cool if it could be restructured in such a way that XRI Resolution 2.0 becomes only an informative rather than a normative reference, but as it currently stands it's used in conjunction with a couple of MUST clauses and therefore needs to be normative. (I was going to put a more readable version of this on the wiki as well, but sadly it seems that OpenID login isn't working today... for me, at least.) ?xml version=1.0 encoding=utf-8? ?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ? !-- ?xml-stylesheet type='text/css' href='style.css' ? -- !-- * File Inclusion * -- !-- The parameter value is the name of the file to be included which can also be a URI. In the case of local files the XML_LIBRARY environment variable provides a search path of directories in which the file may be located. See section 4.1.2 of README -- !-- include=n/a -- !-- * Rigor Control * -- !-- Try to enforce the ID-nits conventions and DTD validity -- ?rfc strict=yes ? !-- * Rendering Control * -- !-- Put the famous header block on the first page -- ?rfc topblock=yes ? !-- Include boilerplate from Section 10.4(d) of [1] (Bradner, S., The Internet Standards Process - Revision 3, October 1996.) -- ?rfc iprnotified=no ? !-- Use anchors as symbolic tags rather than numbers for references -- ?rfc symrefs=yes ? !-- Sort references according to symbolic tags - irrelevant if symrefs=no -- ?rfc sortrefs=yes ? !-- Items useful for reviewing document -- !-- Render cref information -- ?rfc comments=no ? !-- If comments is yes, then render comments inline; otherwise render them in an Editorial Comments section -- ?rfc inline=no ? !-- Insert editing marks for ease of discussing draft versions. Editing marks are strings such as 29 printed at the beginning of the blank line before each paragrpah of text. -- ?rfc editing=no ? !-- Items useful when using xml2rfc to produce technical documents other than RFCs and I-Ds -- !-- Produce a private memo rather than an RFC or Internet-Draft. The value of the PI is used as the title of the document. Omits the topblock and standard boiler plate when . -- ?rfc private=Draft ? !-- Override the center footer string -- ?rfc footer= ? !-- Override the leftmost header string -- ?rfc header= ? !-- * Table of Contents Control * -- !-- Generate a table-of-contents -- ?rfc toc=yes ? !-- Control whether the word Appendix appears in the table of contents. -- ?rfc tocappendix=yes ? !-- If toc is yes, then this determines the depth of the table of contents. -- ?rfc tocdepth=3 ? !-- If toc is yes, then setting this to yes will indent subsections in the table-of-contents. -- ?rfc tocindent=yes ? !-- If toc is yes, then setting this to no will make it a little less compact. -- ?rfc tocompact=yes ? !-- Affects horizontal spacing in the table-of-content. -- ?rfc tocnarrow=yes ? !-- * Format Control * -- !-- Automatically force page breaks to avoid widows and orphans (not perfect). -- ?rfc autobreaks=yes ? !-- Put two spaces instead of one after each colon (:) in txt or nroff files. -- ?rfc colonspace=no ? !-- When producing a txt/nroff file, try to conserve vertical whitespace (the default value was no up to v1.30; from v1.31 the default is the current value of the rfcedstyle PI). Will default to (rfcedstyle) in future. -- ?rfc compact=no ? !-- If compact is yes, then you can make things a little less compact by setting this to no (the default value is the current value of the compact PI). -- ?rfc subcompact=no ? !-- An integer hint indicating how many contiguous lines are needed at this point in the output. Can appear as many times as necessary in the source. -- !-- needLines=0 -- !-- * HTML Specials * -- !-- When producing a html file, use the image in this file. -- ?rfc background= ? !-- Automatically replaces input sequences such as |*text| by, e.g., strongtext/strong in html output. -- ?rfc emoticonic=no ? !-- Generate mailto: URL, as appropriate. -- ?rfc linkmailto=yes ? !-- When producing a html file, produce multiple files for a slide show. -- ?rfc slides=no ? !-- When producing a html file,
Re: Modularizing Auth 2.0 Discovery
Dmitry Shechtman wrote: Then we'd publish in parallel the following two ancillary specifications: * OpenID Discovery for HTTP and HTTPS URIs * OpenID Discovery for XRI URIs. The latter being prepend http://xri.net/ to the XRI and use OpenID Discovery for HTTP. I think as a starting point we should just refactor the existing XRI-related content from the Auth spec into a separate spec. We can then worry about simplifying it as a separate problem. Later, the OpenID community or a third party could publish a specification OpenID Discovery for Email Addresses, but I don't think we're really ready to go there right now. Could you please elaborate on this? I believe the SMTP Extension is pretty solid. The only thing it lacks is formality. I'd rather not get into the debate about email-based identifiers here. This thread is about making it possible to have such a spec, not about which spec will be adopted and when. I encourage you to pursue this separately, assuming we actually do modularize the auth spec. Cheers, Martin ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Modularizing Auth 2.0 Discovery
rob wrote: Martin Atkins wrote: My proposal is that we make the core Auth 2.0 spec scheme-agnostic. It would just state that an identifier is a URI. Later in the spec, where currently it enumerates a bunch of ways to do discovery, it'd just say do discovery on the URI using an appropriate protocol. (or, indeed, words to that effect.) It would also nominate a standard XRDS service type URI to use during Yadis discovery. +1 can we also use the opportunity to put i-names support in an extension? If this were to take the form I described in my original message, effectively *all* discovery mechanisms become extensions. The HTTP/HTTPS one gets special treatment by getting referenced by a MUST in the core spec, but it's still a separate document. i-names would be handled as part of the OpenID Discovery for XRI URIs specification I mentioned. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Modularizing Auth 2.0 Discovery
Drummond Reed wrote: I've always been supportive of breaking out OpenID Discovery into a separate spec. I wouldn't break it out into separate specs, however, because discovery for any OpenID identifier has have much more in common than they have different. For example, they all need to explain the relationship of the identifier being resolve to an XRDS document and the metadata needed to access other OpenID services. My revised proposal is that the Authentication specification would include, as part of a Requirements for Discovery Protocols section, a section on the use of an XRDS document as part of discovery. The separate discovery specs would then describe identifier recognition and canonicalization, how to retrieve an XRDS document and any other special non-XRDS mechanisms as appropriate. So the HTTP/HTTPS one, for example, would: * Describe How to recognise and canonicalize its identifiers * Require the use of Yadis discovery to obtain the XRDS document * Refer to the relevant section of OpenID Authentication for the XRDS processing rules. * Require that if Yadis fails RPs fall back on the non-XRDS-based HTML discovery, describing how this mode returns the necessary information. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Modularizing Auth 2.0 Discovery
Recordon, David wrote: Well there already is the Yadis spec. Maybe the Yadis spec remains separate versus becoming part of the OASIS XRI Resolution document? The XRDS-related parts of the Yadis specification seem to duplicate requirements from XRI Resolution chapter 3. In the interests of avoiding redundancy, I'd suggest the following distinction: 1. XRI Resolution chapter 3 (or a separate spin-off spec) describes the syntax of an XRDS document. 2. Yadis describes how to obtain an XRDS document for an HTTP or HTTPS URL. 3. OpenID Authentication describes how to determine the endpoint URI and other information from an XRDS document, referencing [1]. 4. The new HTTP discovery specification would reference [2] and [3] to describe the XRDS-based HTTP discovery mode, and then go on to describe the HTML-based discovery fallback. Alternatively, [3] above could be served by a separate spec OpenID discovery using XRDS, though I think that may be overkill for something so straightforward. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Modularizing Auth 2.0 Discovery
Drummond Reed wrote: Under this approach, discovery all identifiers (URLs, XRI i-names/i-numbers, email addresses, phone numbers, etc.) would be handled by OpenID Discovery. I disagree that a single spec can contain discovery rules for all conceivable discovery types without becoming ridiculously big. The discovery rules in the current spec for just handling HTTP/HTTPS and XRI discovery are already big enough. However, I clearly have a bias for lots of small specs over one large spec, and clearly your bias is the opposite. :) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Modularizing Auth 2.0 Discovery
Having reflected on people's comments a bit, I have a slightly adjusted set of proposals. 1. Take the bits about parsing XRD service elements from the Yadis spec and call it XRD service discovery for URIs. 2. Have XRD service discovery delegate the actual mapping of a URI onto an XRD element to ancillary specs as before. These will define recognition/normalization rules for user input and how to take a matching URI and return an appropriate XRD element. 3. Create XRD discovery for HTTP URLs which is really just the remaining stuff out of Yadis. * * HTML-based Discovery for OpenID remains a special case, but we can minimize the reach of this special case by stating in the HTTP URLs spec that if HTML-based discovery succeeds an implementation is to synthesize (or at least, act as if it synthesized) a functionally-equivalent XRD element containing Service elements for OpenID 1 and/or OpenID 2. 4. Have OpenID Authentication 2 simply say “use XRD service discovery to find a service description for ‘http://specs.openid.net/auth/2.0/server’ or ‘http://specs.openid.net/auth/2.0/signon’” and then…” and go on to describe the interpretation of the URI element and the LocalID element. It'd also contain a special provision that RPs MUST support HTTP-based discovery, to retain the baseline functionality from OpenID 1.1. The minimal reading for an OpenID Auth RP implementor then becomes: * Core OpenID spec * XRD service discovery * XRD discovery for HTTP URLs While the idea of having three required specs is a little scary, these three should be able to stand alone and the latter two will be quite simple since they are just formed by splitting Yadis in half. XRD discovery for XRIs barely needs defining since XRI resolution already covers most of it. Just need to bring over the recognition/normalization rules from the Auth Draft 11 section 7.2. - This also maps nicely onto a potential set of libraries: * 1 glue library that takes as input a URI and a list of service types in order of preference and returns an XRDS Service element representing the best match. findService(URI, serviceTypes[]) * n discovery libraries which have three operations: isMyIdentifier(string) - determine if this library owns this identifier. normalizeIdentifier(string) - return a normalized version of the identifier. findXRD(URI) - retrieve an XRD element for the given URI. These are called by the glue library and then the glue library parses the returned XRD element. * 1 OpenID library which does: service = discovery.findService(=mart, [ http://specs.openid.net/auth/2.0/server;, http://specs.openid.net/auth/2.0/signon;, ]) endpoint = service.getURI() localid = service.getLocalID() || =mart // etc, etc ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal for Modularizing Auth 2.0 Discovery
Gabe Wachob wrote: Basically, the Discovery Spec would specify that for any identifier scheme to work with OpenID, it MUST define a way of being constructed into an HTTP URI and then returning a XRDS with an HTTP GET on that HTTP URI. If there are other ways of resolving it, then implementations MAY use those other methods of resolution (native resolution, if you will). In essence, this is a requirement for HTTP gateway(s) to whatever resolution infrastructure exists today. I don't really think it's necessary to *mandate* that a HTTP mapping always be used. After all, it's very easy for a spec to, if it's appropriate, define a mapping to an HTTP URL and then reference the HTTP-based discovery spec. While I agree that at this point any discovery protocol that *doesn't* use HTTP is going to face an uphill struggle as far as real-world implementations go, if people want to go ahead and try to get their off-the-wall protocols adopted I don't see any reason why we shouldn't let them. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: HTTPS status
Alaric Dailey wrote: Eddy Nigg and I brought up the issue of requiring SSL a while back, since then I have been swamped, it looked like there was some more talk about it since then. I know that there are several other people, that are concerned about this too, and it has even been blogged about ( http://www.tbray.org/ongoing/When/200x/2007/02/24/OpenID ) Can someone please tell me the status on this? Hopefully its being required! As far as I'm aware, the current status is: * All OpenID identifiers SHOULD use a secure channel. * All OpenID servers SHOULD use a secure channel. * OpenID relying parties MUST support SSL access to HTTP URLs. * OpenID relying parties MAY refuse to interface with identifiers and servers that do not use a secure channel. * All other connections are out of scope of OpenID Authentication. I may be wrong on these, as I'm listing them from memory. In practice, I expect all big OpenID providers will support SSL because users will demand it. The sites currently providing OpenID identifiers as value-add features alongside an existing service (LiveJournal, etc.) probably won't get used much once there are more proper providers. People hosting their own identifiers and/or OPs probably won't use SSL, but then they won't be able to use their identifiers at any site which requires SSL-based OpenID Authentication, and they'll be in the minority anyway. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Wiki page: Attempting to document the Email Address as OpenIddebate.
Hallam-Baker, Phillip wrote: Over time everyone will own their own DNS domain and it will form the hub of their personal communications system. All communication modes will map onto the single unified communication identifier. I don't necessarily disagree with many of your arguments, but I wonder why — if everyone owns their own DNS domain — we even need the user@ portion anymore? Largely that was included because in the early days — and even today, for many people — their addresses were [EMAIL PROTECTED] My primary personal email address (not the one I use for mailing lists) is pretty redundant since the part before the @ is the same as the part after the @ once the parent domain has been excluded. Leaving off the user@ portion doesn't make the address any less mine. An 'email' address is simply the conventional conjunction of a username portion and a DNS name portion. It need not be used only for email, nor is it. It is routine for people to use RFC822 addresses for Jabber and other instant messaging applications. Calling a Jabber ID an email address is a bit misleading. It's entirely possible for the email address [EMAIL PROTECTED] and the JID [EMAIL PROTECTED] to be owned/controlled by different people. It is not safe to assume that the two are the same person without evidence of that. What makes a string like [EMAIL PROTECTED] an email address is the fact that you can address email to it. The fact that the two addressing schemes use similar syntax doesn't help you much. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
Recordon, David wrote: I agree that things like age should be in an extension, though I think this single piece of data is useful in the core protocol. I'm sure the exact definition of phishing resistant will come back to bite us in sometime in the future, but lets deal with it then instead of not adding anything now. I really like the idea that there be one thing in the core spec which reaches out to each extension. I propose: openid.make_it_work=1 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OA2.0d11: Minor nit-pick regarding normalization
Hi, This is a really minor thing I just spotted due to leaving my browser open on the relevant part of the spec and coming back to it later. :) The normalization table in appendix A.1 lists several examples of the normalization of URIs. The last few examples are as follows: http://example4.com/ = http://example4.com/ https://example5.com/ = https://example5.com/ example6.com = http://example6.com I believe that the last example should instead normalize to: http://example6.com/ * A HTTP URL without a path is a nonsense because the protocol doesn't allow for an empty path anyway. (You can't GET empty string HTTP/1.1) * It's causes http://example6.com/ and example6.com to normalize to different strings, which is counter-intuitive. * There is no useful reason to omit that slash except that the currently-specced normalization rules exclude it. Therefore there should be an extra provision in section 7.2: * If the resulting identifier is an HTTP or HTTPS URL and it contains only the two slashes after the protocol specifier, an additional slash MUST be appended to the end of the string. (not fussy on the exact wording.) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: HTML parsing in HTML-based discovery
Claus Färber wrote: In order to facilitate regexp parsing, just requiring the start and end tags is not enough. Additional restrictions may also be necessary to avoid cases where too simple regexp-based parsers might fail: - head start with attributes. - order of attributes within the LINK tag. - single quotes vs. double quotes vs. no quotes. - unescaped / within attributes.* - numeric character references.* - line feeds within tags.* - additional XML namespaces that allow attributes like foo:href.* - LINK tags within !-- comments --.* - [to be continued] (* = inspired by a real-world implementation failing to handle these cases correctly) And, in theory, the OpenID spec could add additional restrictions to fix the above problems. Whether it should or not is of course up for debate; I'd be interested to hear from Brad Fitzpatrick and JanRain's developers who are responsible for the most-used implementations currently using regex parsing. Why didn't you guys use an HTML parser? I assume there must have been a reason. This is mostly an ideological argument founded on whether we're allowed to impose additional restrictions on HTML documents that are making use of OpenID discovery. There is certainly no *practical* reason why this shouldn't be done, assuming that the restrictions are sufficient to prevent the above attack. There are practical problems: * Users can't use existing HTML tools to check for the additional restrictions. A validator will say valid HTML but the OpenID login fails due to a parsing error (e.g. the PHP implementation used on OpenID Enabled). And different RP will choke on different things. An HTML validator also won't help them if they transpose the values of openid.server and openid.delegate, or if they type rel=opnid.server instead. There are OpenID-specific validation/checking tools in the works which will hopefully be able to give users good information about potential pitfalls with the way they have written their HTML in addition to pointing out things like that the openid.server LINK is missing. * Users can't use existing HTML tools that do not honor the additional restrictions. A HTML pretty-printer may simply re-format the code in a way unparsable by ad-hoc parsers; a hypothetical htmlcrush program might may remove the optional quotes, entity references and tags in good faith. Indeed. But those documents wouldn't conform to the OpenID specification. (assuming that it went into more detail about the restrictions it is adding to HTML.) I think the main point here is that despite the outcome of this debate people *will* write regex-based parsers, whether the spec allows for it or not. We have a choice between ignoring the issue so that all of these regex-based parsers fail in interesting ways on odd cases, or accepting that this is inevitable and listing in detail a set of rules for regex-based parsing in addition to a set of restrictions on HTML that make those parsing rules possible. I'd love it if everyone would use proper HTML or XML parsers, but that just isn't going to happen no matter how much we wish it would. In the end almost there but not quite implementations hurt no-one but the end-user, and OpenID is what will get the blame for any negative user experience, not the libraries that use incompatible regex-based parsers. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID.net Service Type Namespaces
Recordon, David wrote: http://specs.openid.net/authentication/2.0/signon http://specs.openid.net/authentication/2.0/server http://specs.openid.net/authentication/2.0/identifier_select These seem just fine to me. (+1, I guess!) So very verbose and organized. There is no need for an xmlns for the Auth 2.0 spec itself, since unlike the 1.1 spec which defined OpenID:Delegate in Yadis, 2.0 takes advantage of the LocalID element already defined in the XRD schema. I missed the change to using LocalID. I'm glad to see that change, but really just because I've always hated the fact that it was called Delegate in Yadis. :) http://specs.openid.net/extensions/ABBREV/VERSION This naming scheme doesn't separate out extensions by what they're extending. Presumably in future we're going to have other non-extension specs (that is, they don't actually use the OpenID Authentication request as a transport) which will themselves have extensions. How about, http://specs.openid.net/authentication/2.0/exten/simplereg/1.0 I've not got my heart set on abbreviating extensions, but I don't really like URLs that are longer than one line in a plaintext email because then people start wrapping them over multiple lines. :) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Exchange
Recordon, David wrote: Awesome, glad to see this! Would be great as Johannes said to see some flow examples and how you'd see it integrate to do something like exchange profile data or post a photo on your blog. Would love to see this formalized and happy to help however I can! I'm hoping to get some working demo examples done this weekend in some form or other, if I get time. Failing that, I'll at least try to get some written, theoretical examples written up for the scenarios I listed in my original message. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Assertion Quality Extension = openid.importance
Manger, James H wrote: A related hassle is that when my OP supports a new authentication method (such as a strong password-authenticated key agreement scheme (eg SRP)), existing RPs will not recognize this method as strong enough for the RP’s expectations – regardless of the method’s actual strength. Consider also that non-human agents can often be both the OP and the user at the same time (they specify a URL under their own control as the OP, generate their own signature and respond) and in this case the OP knows that the user is the user without any shadow of a doubt because it *is* the user. However, this scenario would fail in any situation where a particular authentication scheme is demanded because there is *no* traditional authentication in this scenario. However, if the RP instead presents (for example) a list of keywords identifying (in vague terms) what is at stake: transaction_involves=money+personal_details ...my non-human agent can pick up that it's being used for something for which it is not intended and refuse to take part. My traditional OP, on the other hand, can present me with a set of options (with reasonable defaults) for what to do in the presence of these keywords so that anything involving money can force a re-authentication (again, for example). Whether a list of keywords is the way to go remains to be seen, but I believe this is the most sensible approach in principle. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Assertion Quality Extension = openid.importance
Justin S. Peavey wrote: I fully agree with you in your example above until you mention money. In the Amazon example for book purchases, the user is not the one affected by a mis-authenticated transaction, Amazon and the credit-card companies are; the user is indemnified by most credit card companies for fraudulent purchases. If the user was *actually bound* to be responsible for the transactions their identities perform, the model works - but this is not the world that I (or Amazon, or Bank of America) live in. Is anyone really expecting an OpenID identity to be used in place of a credit card number? Perhaps I'm just not seeing the advantage of this, but I would expect that most organizations carrying out credit card transactions would: * Use OpenID to authenticate the user against the account to gain access to the purchase history, returns, enquiries and such. * Demand the user's credit card before actually performing any transaction. While I'll admit that Amazon and PayPal currently store credit card details and require (in some cases) only the password to be entered, it can hardly be argued that my Amazon password is any more secure than my IdP password. In Amazon's case they still don't let you make a purchase knowing only the password in most cases; you have to provide all or part of the stored credit card number or other authentication details. But this is all beside the point given the fact that the OP *is always in control* — there is NO WAY that the RP can tell what the OP really did. The OP can lie, the OP can have a bad implementation of a given authentication scheme or the OP might not even be a traditional OP at all. I don't really see the value in presenting a protocol which gives an illusion of control to the RP; it just seems dishonest. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID Exchange
I have made an early draft of a spec called OpenID Exchange on the wiki: http://openid.net/wiki/index.php/OpenID_Exchange_1.0 The goal of this protocol is to allow user-accompanied HTTP requests. user-accompanied means that a consumer makes a request to a service on behalf of a user and the user reviews and approves the request. Example applications of this include: * Zooomr posting photos into your blog with your one-time approval, without disclosing your login credentials. [1] * Fetching of user profile information. * Social networking friendship handshakes. [2] The protocol should, in theory, be able to act as a transport for any HTTP-based protocol such as SOAP and AtomAPI, as well as for simple GET requests. The protocol for post in my blog could, for example, just be an AtomAPI POST request made over OpenID Exchange. This is still work-in-progress. The spec needs lots of refinement and at some point I'll have to make a demo or two. [1] You can still see the results of the demo of my earlier version of this on LiveJournal, albeit without the pictures: http://openrpcdemo.livejournal.com/ [2] Discussed further in my blog entry on social networking: http://www.apparently.me.uk/623.html ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consistency of negative responses to checkid_immediate requests
Josh Hoyt wrote: It's confusing to me make the failure response to an immediate mode request be id_res, especially if that is not the failure response for setup mode. I can't see a reason that they can't both use the cancel response to indicate that the OP or end user do not wish to complete the transaction. This is a very minor change, but it will make the spec simpler. I think the RP will want to do something different in these two cases. In the cancel case (which indicates that the user cancelled the request in some way) the RP will probably return to the login form to invite the user to try again. In the checkid_immediate case, what needs to happen is that the RP must start a checkid_setup request instead, since a negative response in the checkid_immediate case generally means I can't answer this until I've presented some UI to the user. I suppose it could be argued that the RP should know what it's doing and be able to distinguish between these cases using its own state, but given that the meaning of these responses is different I don't think it's a problem that the messages are different. It'd might be nice if the checkid_setup error response were called something other than id_res, though. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Assertion Quality Extension = openid.importance
Manger, James H wrote: The user-centric solution is not for the RP to specify a max auth age (or captcha or email verification or handbio or hardotp…), but for the RP to indicate the importance of the authentication. The user (with a little help from their OP) decides how to react (eg whether or not to login again) based on the importance/RP/auth-age/…. I like this approach a lot more. It seems a lot more honest as to what's really going on, and it leaves protecting the task of user's interests in the IdP's hands where it belongs. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Assertion Quality Extension = openid.importance
Paul Madsen wrote: Is there not a potential contradiction between an RP expressing both of 'this is very very important to me' and 'I leave it to you as to the specifics'? Perhaps, but that is the case in both the IdP reports and the RP suggests case: either way the IdP is calling the shots, but the RP suggests case is more honest about who is in control. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID IPR Policy Draft
Recordon, David wrote: http://openid.net/wiki/index.php/IPR_Policy Is it really possible to use mailing list subscription as a trigger for a contract like this? The whole idea scares me a little bit, to be honest. It seems more sensible to me to put these restrictions on actual *contributions*: require that any proposal or concrete specification/implementation offered via the mailing lists or other official channels to come with patent disclosure, and only *then* are any undisclosed patents assumed to constitute a royalty-free, perpetual licence. As it is currently written, I think lots of companies that retain software patents of any kind — or even ones that don't but may wish to in the future — would be put off contributing due to the risk that their patents may be implicitly licenced to everyone. I'm not a lawyer, of course. However, not everyone who could potentially be affected by this is a lawyer either, so putting in stuff that potentially scares non-lawyers like myself is probably a bad idea. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Yet Another Delegation Thread
Pete Rowley wrote: Actually I think this is a consequence of using URLs as identifiers and wanting to use my site to host the portable identifiers - you're probably thinking separate domains per portable identifier or using some well known IdP. Each identifier can be correlated by inference in this case since they are on the same site. Non-correlatable identifiers would need to either be on separate sites or be hosted as a service and thereby taking advantage of the lost in the crowd effect. This is true, but this is an implementation decision you can make for yourself. If you want to make an identifier that has no links to any of your other identifiers, there's no reason why you can't choose to use an arbitrary IdP-issued identifier that has no connection with any others. You lose the identifier portability, but this is a trade-off you must make on your own. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Yet Another Delegation Thread
Dick Hardt wrote: The RP can't trust state that it has sent to the IdP since the message may have been modified in transit between the RP and the IdP. Perhaps someone can explain what state needs to be maintained? And if the RP wants to put state in the message, I thought we had that as data in the return_to? The RP likely needs to sign that in some manner to know that it was not modified as well. The current stateless RP implementations just repeat discovery when they get back the signature. There is therefore a slim chance that the request had been modified to change the claimed_identity to another identifier owned by the same user and delegated to the same IdP identifier at the same IdP. However, aside from this rather odd attack the second discovery is sufficient to avoid the need for RP state or signatures. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
Dick Hardt wrote: On 21-Oct-06, at 10:52 PM, Josh Hoyt wrote: On 10/21/06, Dick Hardt [EMAIL PROTECTED] wrote: 2) the RP does not verify the binding between the portable identifier and the IdP-specific identifier in the response. to the one the attacker controls and the IdP has mapped This is the part where I think you're wrong. The RP MUST verify that binding, whether it is by keeping state, self-signing the request (which gets passed through to the response) or doing discovery again. I agree the RP SHOULD do that. The proposal does not specify that. I thought we had that conversation. I have not looked at the patch that you sent. Perhaps you address the issue there. My point though is: why have the RP bind the IdP-specific identifier and the public identifier? Why not let the IdP be responsible for this? In 1.x when the IdP was not aware of the public identifier, then the RP had to do the binding. Now that the IdP is aware of the public identifier, it would be simpler and logical for the IdP to be responsible for the binding. It is doing it anyway. All the RP wants is which public identifier is the user, and is the IdP authoritative for it. If delegation is going to require cooperation from the IdP anyway, there's no longer any value in having the distinction between a public identifier and an IdP-local identifier. The hypothetical IdP IdP-tastic can just store a relationship between http://mart.vanitydomain.com/ and my user account at IdP-tastic. There's no need for http://mart.idp-tastic.com/ anymore, and with that gone delegation is no longer useful: the public identifier, whatever it might be, is the only identifier. Any disadvantages to uniting the public identifier and the IdP identifier are also disadvantages of having the IdP do the binding as you describe. For simplicity's sake, I'm currently only willing to vote positively for one of the following scenarios: * Have only one identifer in the protocol. Remove delegation entirely. IdP maintains relationships between arbitrary identifiers and its local user accounts. IdP no longer needs to issue its own identifiers, though it can if desired. This makes life simpler for RPs, but has the risk that delegation would become an IdP premium feature, which may hurt users in the long term. * Protocol has two distinct identifiers: public and IdP-local. Relying party manages delegation. IdP does not even know that the delegation has taken place and has no way to stop it happening [1]. RP now has to do more work, but identifier portability now comes for free. Having the IdP deal with the public identifier while still keeping the IdP-local identifier (and thus delegation) is, it seems to to me, muddled nonsense; the whole purpose of delegation was to make these identifiers distinct. [1] Conceivably a mischievous IdP could make use of knowledge of how particular RPs round-trip their delegation state to block it, but that would be an arms race in the RP's favour rather than a designed-in mechanism for detecting delegation. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Login Page Link Tag
Drummond Reed wrote: I initially agreed as well. But to play devil's advocate, the link-to-XRDS option could actually be pretty efficient. Any HTML page could simply advertise the availability of its Yadis XRDS file using an XRDS link in the header. Assuming that many or all of the pages on a site would be covered by the same XRDS file, the browser would only need to download it once to cover the entire site. The XRDS would expire (using the same cache control that XRI resolvers use) and be refreshed as needed. This is the architecture that P3P used (http://www.w3.org/TR/P3P/#ref_syntax). The XRDS file could provide discovery of multiple services representing the RP, not just the login page. This is not incredibly different to what happens when you have a site-wide CSS stylesheet. In fact, it is possibly *better* than that situation since you don't need to delay page rendering while waiting for the Yadis document to download. I wonder, though, whether we are asking too much of browsers' plugin interfaces? This is an honest question, as someone who's never written a browser chrome plugin before. I guess IE's ones are just COM objects and can thus do whatever they like, but what of Firefox? Chrome overlays? Does that mean that they can access the HTTP component somehow to make HTTP requests? I think Opera's pretty unlikely as it has no real plugin interface to speak of. I have no idea at all about Safari. Anyone care to elaborate? There's no point in speccing something that's unimplementable, but it's probably okay as long as IE and Firefox can do it; the others can just catch up later. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Discussion: RP Yadis URL?
Recordon, David wrote: I'm torn if this parameter should be added to the spec at this time or not. Adding the parameter is conceptually simple, though I don't think there is agreement on what the RP should be publishing in their Yadis file. There is the section http://openid.net/specs/openid-authentication-2_0-10.html#anchor42 which has the RP publish a return_to URL, though the section was meant to be removed as that URL may not be the right entry point to start a transaction. I would say that what's inside the Yadis document is outside the scope of OpenID Auth. It's simply a hook to enable extensions that must be instrumented at the RP side. In other words, OpenID auth just needs to specify how to find an RP's Yadis document. The rest is for other people to figure out. That is the point of Yadis, after all. (and then this IdP-initiated login thing could be an extension built upon this ability, and thus not hold up Auth 2.0.) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
Chris Drake wrote: There seem to be a lot of people on this list who want to hate and loathe the IdP, and grant all power to the RP. I do not understand this reasoning: our users will select the IdP they trust and like, then they will be using a multitude of possibly hostile RPs thereafter: the reverse is simply not true. If I'm using one IdP to assert my primary public identity, they can hypothetically develop quite a profile about me. I probably don't mind too much in most cases, because I researched them and found that they are a good provider and won't sell my data out to the bad guys. However, there might be some things I want to do (for example, posting locally-prohibited speech on a public forum) that I don't want attached in any way, shape or form to my public identity. The trust relationship I have with that IdP probably isn't enough for this; if there is any record at all of any association between these two identities, as friendly as my IdP may be, there is a chance that it will be ceased by court order, or leaked by an insider, which might lead to me getting in serious legal trouble. This is just one (perhaps extreme) example of why my trust in my IdP is not universal and all-encompassing. Trust is not a boolean. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
Brad Fitzpatrick wrote: Counter-argument: but OpenID 1.1 does have two parameters: one's just in the return_to URL and managed by the client library, arguably in its own ugly namespace (not IdP/RP managed, not openid., but something else... the Perl library uses oic. or something). So then it's harder to document the correct behavior to people (RPs should verify the mapping when you get a signature!) because the parameter names aren't consistent between RP clients. Not specifying it gives RPs the freedom to put whatever handle they want in the return_to, though. If they *are* able to maintain state, they might have some arg like ?handle=1380a383198bcefd933, which is completely opaque to everone except the RP. I'd rather avoid specifying things we don't need to specify, since it leaves more flexibility for implementors in an area where this flexibility doesn't do any harm. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
Dick Hardt wrote: Won't the IdP will still have to resolve the i-name? The IdP can't trust the RP, or know that the i-name and i-number are really linked unless it checks itself. The IdP is only authenticating the i-number. The i-name is for display to the user and possibly to allow the user to choose that as the display identity to send back to the RP. The only attacks possible are: * RP tries to fool the user into authenticating as a different i-number by sending a false i-name. I'm not sure what the benefit of this attack would be for the RP. * The RP tries to convince the IdP to send back an incorrect display identity back in the response. But then the RP is just fooling itself! The spec should probably contain some words to say that the IdP should not do any processing on the public identifier (whether it be a delegated HTTP URL or an XRI) that relies on the i-name to i-number mapping without first ensuring that the mapping is correct; any such processing would be outside of what is required for the Auth spec, though. Assuming for the moment that we've conceptually separated the public identifier from the IdP token per my proposal, the public (delegate) identifier or i-name is for the RP (it checks the mapping), and the IdP token (which is some URI that doesn't necessarily even have to be resolvable) is for the IdP. Both parties validate their own token; if either party doesn't validate its own token, it opens itself up to the other party telling lies. However, they do not have to authenticate *each-other*'s tokens. The RP's validation of its own token is defined by the spec. The IdP's authentication is not defined by the spec; the IdP doesn't necessarily even have to resolve its own tokens, but it can do if it wishes. Lastly, in the case where the identifier-the-RP-stores and the identifier-the-IdP-stores are different, if the RP has already discovered the latter, then the RP can be stateless by sending both to the IdP, knowing it will receive both back in the response. Then the RP is trusting the IdP will send back a correct mapping. This one bothers me too. Unless the RP can sign its initial request parameters to stop the IdP from tampering with them, I don't see how the RP can trust the IdP to return a correct mapping. My old stateless RP demo implementation just re-resolved this stuff when it got back the response to make sure that the IdP was telling the truth. I'd love to hear that this was unnecessary, since it did double the identity resolving overhead. This discussion has me wondering about XRI resolution though. Given that multiple i-names can resolve to the same i-number, just as multiple domain names can resolve to the same IP address, and that the i-name is the identifier the user sees, it would seem tht the i- name is what should be stored by the RP, otherwise there is no difference between using any of the i-names that resolve to the same i-number, or is that the idea? I think this is the intention, though it does show an interesting inconsistency between the use of XRIs and the use of i-numbers. I currently have three URL-based identifiers all pointing at the same server and the same Yadis document, yet those identifiers are distinct. However, in the comparable XRI case, it would appear that those identifiers would all be considered to be the same. I wonder how easy it is to get hold of new i-numbers. If they are basically throw-away cheap, then I'm able to decide for myself how to distribute my mappings to separate them. However, if these i-numbers are going to be expensive (for some sense of the word) to aquire, I've got less freedom in this respect. Drummond? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Delegation discussion summary
Drummond Reed wrote: +1 to getting it done. This area of terminology is more a usability/marketing issue at this point. I agree we need to converge on good, simple user-facing terms for describing OpenID in ways ordinary Web users can easily understand. Although I have great respect for Dick Sxip’s pioneering work in this area, I don’t believe terms that use the word “site” are the right metaphor, and the concept of “membersite”, while good for the context Sxip originally used it, would send the wrong message about OpenID. But I suggest we move that terminology discussion to the marketing list. What marketing list? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] request nonce and name
Marius Scurtescu wrote: On 12-Oct-06, at 5:07 PM, Josh Hoyt wrote: On 10/12/06, Marius Scurtescu [EMAIL PROTECTED] wrote: If passing through all unrecognized parameters can cause problems then there could be a special namespace for this purpose. For example, all parameters with names starting with openid.pass. should be ignored by the IdP and passed back to the RP. Yahoo Browser-based authentication [1] has a single parameter called appdata (that you can find in [2]) that is used for this purpose. This seems general enough to me. True, even one single pass through parameter should do. This causes the minor inconvenience that the RP will probably now have to implement its own parsing, rather than using the framework's pre-supplied functions for dealing with urlencoded query strings. Not a major deal, but I'd guess that this is where the idea to use return_to args came from in the first place. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] request nonce and name
Recordon, David wrote: We thus believe that any state tracking needed by a stateless RP must be maintained as GET parameters within the return_to argument. In the case of a stateful RP, it can either do the same thing, or store state via other means such as using a session id within a cookie to reference database data. Sounds good to me. +1. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
Recordon, David wrote: Dick, It is needed in the case where there is delegation with a URL, openid.identity is the actual URL on the IdP and then openid.rpuserid is the URL that the user entered which delegates to openid.identity. This is then also used in the similar case with XRI delegation. Does the IdP really need to know what URL I gave to the RP? Earlier versions handled this adequately by the library including implementer-defined variables in the return_to URL, which allows a stateful RP to hide the real identifier behind a meaningless session token, which satisfies Brad's criteria that the RP should be able to hide from the IdP the fact that delegation is in use. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Strong Authencation (was [PROPOSAL] authentication age
Chris Drake wrote: Hi All, 1. Amazon asks the IdP Please assert this user is not a Robot How can it trust this occurred? 2. Amazon asks the IdP Please re-authenticate this user, via two-factor, two-way strong authentication How can it trust *this* occurred? The IdP can *say* it did, but would RPs prefer a stronger role to encourage adoption? (eg: #1 - the RP provides the captcha, and the hash of the solution, while the IdP returns the solution, or #2 - the RP provides a nonce and later looks for this nonce in the IdP's also-signed-by-the-authentication-vendor-technology response) i.e.: It might get ugly to try and add this stuff in later if we've not catered up-front for these kinds of interchanges. These use-cases seem like a good one, in that it's something that's actually *verifiable*, rather than relying on a trust relationship that probably doesn't exist between RP and IdP. I still don't think this should be in the core spec — core OpenID Auth should be simple — but we should make sure that it's possible to add it via extension and if it isn't adjust the way extensions work to make it possible. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
