Re: IDMML (was RE: Using email address as OpenID identifier)
Hi Drummond,
I pushed hard for RP identification for 2 or 3 months back around
October 2006. If anyone wants to go back through the archives,
there's a pile of other important reasons to have some way that an IdP
and/or browser agent can identify an OpenID-enabled site. The antique
thread below lists a few. My proposal too was a tag.
Kind Regards,
Chris Drake
Tuesday, November 7, 2006, 12:51:15 I, you wrote:
CD> Hi Johannes,
CD> I proposed a solution to the "single sign out" problem a month or two
CD> ago.
CD> In fact - a whole range of solutions have been proposed, and relative
CD> merits of all discussed already - does anyone have the free time to go
CD> back over the postings, extract all the knowledge & contributions, and
CD> document them all?
CD> To summarize my proposal - I was seeking a standardized OpenID RP
CD> endpoint interface into which I (as an IdP) or a software agent (eg: a
CD> browser plugin) could "post" user information - be this a login
CD> request, email change request, log-out request, account signup,
CD> account cancelation, or whatever. My preferred implementation was a
CD> tag placed on (and thus identifying) a login page, and within
CD> the link tag, the endpoint of the RP for accepting IdP(OP/agent)
CD> input.
CD> Kind Regards,
CD> Chris Drake
CD> Tuesday, November 7, 2006, 1:04:44 PM, you wrote:
JE>> I continue to believe that we need single-sign-out
JE>> functionality, in particular once OpenID moves up the stack for
JE>> higher-value transactions.
JE>> Some people have made the case that that is undesirable
JE>> and/or impossible; I beg to differ.
JE>> Having automatic authentication against the IdP is quite
JE>> similar to not having a password on the identity at all, in that
JE>> it reduces the confidence that we know the real-world identity of
JE>> the entity/user at the other end. In my view, there's nothing
JE>> wrong with that, but we do need to be able to convey that to
JE>> relying parties in a way that cannot be easily attacked.
JE>> On Nov 6, 2006, at 16:41, Joshua Viney wrote:
JE>> One question re: User Experience and single-sign-on comes to mind:
JE>> How do we treat users who are accessing their IdP and
JE>> Relying Parties via public computers?
JE>> Use Case:
JE>> Good User at public library wants to leave a comment on Blog X
JE>> Blog X requires the person to authenticate via OpenID
JE>> Good User enters their OpenID and successfully authenticates
JE>> via email and password (or whatever) (and authorizes the RP
JE>> ('realm' in 2.0) if necessary) at their IdP
JE>> Good User is redirected to Blog X signed in
JE>> Good User leaves comment
JE>> Good User signs out of Blog X (if sign out is even an option)
JE>> Good User then leaves the public library and goes shopping
JE>> Evil User jumps on computer and proceeds to leave comments at
JE>> any number of OpenID enabled blogs using Good User's OpenID (he
JE>> saw it while looking over Good User's shoulder, or he checks any
JE>> sites that Good User did NOT sign out of that might display his
JE>> OpenID)
JE>> Evil User, uses Good User's signed in IdP session to sign into any number
of sites, etc
JE>> Outcome: Good User's reputation is ruined and his/her OpenID
JE>> is banned from a whole list of Relying Parties. Good User then
JE>> blames their IdP, the Relying Parties and OpenID as a technology
JE>> and tells everyone he/she knows not to use it blogs about it and
JE>> initiates a press release.
JE>> It may be easy to pass this off as an implementation specific
JE>> issue or as "user error", but this use case is somewhat likely for
JE>> 2 reasons:
JE>> 1. A user's OpenID URI is not necessarily a private thing
JE>> (obscurity is not security anyway)
JE>> 2. Users will be at least 1 site removed from their IdP while
JE>> accessing a Relying Party, and no one is use to signing out twice
JE>> 3. It is very very likely that IdP's will use some type of "remember me"
functionality
JE>> One solution to consider would be a global sign-out feature
JE>> on relying party sites that signs users out of their IdP as well.
JE>> Another solution would be to make very specific recommendations
JE>> about messaging users who may be using public computers.
JE>> Josh Viney
JE>> http://www.eastmedia.com -- EastMedia
JE>> http://identity.eastmedia.com -- OpenID, Identity 2.0
JE>> ___
JE>> user-experience mailing list
JE>> [EMAIL PROTECTED]
JE>> http://openid.net/mail
Re[2]: OpenID Email Discovery
Hi Phillip, I wasn't aware that DNSSEC existed yet (outside a few obscure European TLDs?). Since you appear to work for Verisign, and I'd like to set this up - can you please send me a URL when I can obtain a signed DNSSEC certificate for my .COM domain ? Kind Regards, Chris Drake Saturday, January 5, 2008, 6:18:14 AM, you wrote: HBP> You can use domain validated SSL certificates or DNSSEC here. Either is sufficient. HBP> There is no technology gap here. >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Artur Bergman >> Sent: Friday, January 04, 2008 6:14 AM >> To: Trevor Johns >> Cc: 'OpenID specs list' >> Subject: Re: OpenID Email Discovery >> >> >> On Jan 4, 2008, at 12:07 PM, Trevor Johns wrote: >> >> > On Jan 4, 2008, at 1:59 AM, Artur Bergman wrote: >> > >> >> Fair or not, I am tired of hearing how un-secure DNS, when >> everything >> >> we do is based on it, and it being the worlds largest working >> >> distributed database. >> > >> > There's a difference between working and secure. For example, email >> > works great but it's far from secure. >> > >> >> Whatever, this discussion is old and bores me. You can always go out >> and use DNSSEC. >> >> >> There is SSL connecting to the provider that is being refereed >> >> from the srv/txt field. Which is no different than what you are >> >> referenced to from an A or CNAME or MX >> > >> > Which is why I said it depends on what is used as the claimed >> > identifier. If the user's email address is used as the claimed >> > identifier and I am able to change the user's record from: >> > >> >example.com TXT OpenID * 10 https://*.example.com/ >> > >> > to: >> > >> >example.com TXT OpenID * 10 https://*.myevilsite.com/ >> > >> > then all the SSL in the world won't help. >> > >> > If the email address _isn't_ the claimed identifier, then the end >> > user has to validate that their OP-local identifier (which they >> > don't know) is displayed correctly by the service provider. >> This is >> > worse than an SSL failure, there isn't even a dialog asking >> them to >> > click OK! >> > >> >> Not that it matters anyway, since people just click OK. >> > >> > >> > If a service provider detects an SSL failure, there's no person >> > there to press okay. Their server will just summarily deny the >> > authentication request. >> > >> > The "click OK" problem is only between client-server >> communication. >> > This is server-server communication. >> >> Isn't this just a lookup of email address -> openid/url that is then >> handled as a normal openid login? >> >> Artur >> >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs >> HBP> ___ HBP> specs mailing list HBP> specs@openid.net HBP> http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: [osis-general] OSIS PAPE call results
Hi, A quick comment: "... End User does not provide shared secrets to a party potentially under the control of the Relying Party ... " So if the secret gets provided to any third party - so long as it's not a party under control of the RP - it's *not* phishing ? I think what everyone's trying to say is that "Phishing-Resistant" means "End Users can't be tricked into giving things to the wrong place"... is all the jargon/terminology/verbosity really necessary in the definition? Kind Regards, Chris Drake ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: [Idschemas] identity schema element metadata: using existingspecifications
Hi, Having missed the summit - can anyone tell if there was any dissent or scaremongering going on? The idea of assisting everyone who's collecting information about me, to share it easily, seems like an exceptionally "Bad Idea" (tm). If anyone's building anything that assists these companies to "give up" or relinquish their collection of my data, in favor of letting me hold the one single master copy if it myself, on my chosen IdP, and to let me arbitrate who can use it, when, and how - now *that* would be something to congratulate people about. Search google/google-news for "paper shredder" ... Kind Regards, Chris Drake, =1id.com Saturday, September 8, 2007, 5:33:20 PM, you wrote: DR> Mark, DR> I just wanted to say that based on what I learned about them at the Data DR> Sharing Summit (http://datasharingsummit.com) today, and what I read on my DR> first pass tonight, these are fine pieces of work that really push the ball DR> forward. DR> Hats off to you. DR> =Drummond >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:idschemas- >> [EMAIL PROTECTED] On Behalf Of Mark Wahl >> Sent: Thursday, September 06, 2007 6:05 PM >> To: ID Schemas >> Cc: OpenID specs list >> Subject: [Idschemas] identity schema element metadata: using >> existingspecifications >> >> >> I'm reformatting the table of identity schema metadata, located at >> http://idschemas.idcommons.net/moin.cgi/MetaData, into a >> pair of more compact and usable specifications. One spec describes >> where the existing well-known metadata (e.g., Dublin Core) should be >> used when describing identity schemas and their schema elements (i.e., >> attribute types and claim types). The other spec will describe how >> to represent identity schema metadata for which there is no >> pre-existing well-known specification. I've attached a copy of >> the first draft of the "Identity Schema Element Metadata: Using >> Existing Specifications". >> >> Mark Wahl >> Informed Control Inc. >> DR> ___ DR> specs mailing list DR> specs@openid.net DR> http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier recycling write-up on the wiki
Hi Josh, You've got 6 points under the "use cases", but it's really just 1 use case, and then 5 consequences recycling. Is there room on your Wiki for opposition? It's only going to take one screwup and an angry victim someplace and the whole recycling issue could bankrupt someone in the prevailing "identity theft" lawsuit. Why would any responsible Identity provider want to give a past identity to a new person, and why would we want to encourage this misbehavior by supporting it ? Kind Regards, Chris Drake Saturday, June 16, 2007, 9:23:06 AM, you wrote: JH> Hello, JH> I spent some time thinking over the issues and going over the JH> discussions that have happened about identifier recycling, and I wrote JH> up what I understand about the issue on the OpenID.net wiki [1]. I JH> think that my best contribution was to try to come up with as many use JH> cases as I could that related to identifier recycling. I'd love help JH> in fleshing out the use cases that I came up with, or additions of any JH> use cases that I missed. JH> I also wrote up what I knew about each of the proposals for JH> implementing identifier recycling on its own wiki page. Those pages JH> are linked from the page with the use cases [1]. I hope that these JH> documents can help us to reach a conclusion about identifier JH> recycling. I tried to keep commentary and bias to a minimum. (You get JH> enough of that from me here on the mailing list.) JH> I hope that by refining these proposals on the wiki and fleshing out JH> the use cases, we can understand the problem better and home in on the JH> solution that best solves the problem. JH> Josh JH> 1. http://openid.net/wiki/index.php/Identifier_Recycling JH> ___ JH> specs mailing list JH> specs@openid.net JH> http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: Specifying identifier recycling
Hi, OpenPGP keys can be "resolved" using key servers - for example - here's mine: http://pgp.mit.edu:11371/pks/lookup?search=0xc0ded00d&op=vindex&exact=on In the old days, they used "key ID" to find these things, but they stopped doing that and started using fingerprints when people like me worked out how pick our own key ID's :-) I don't think public keys for identifiers are a good idea. I know you're all sick of me whining about privacy, but once again - these things "leak" all kinds of information about the victim... err.. owner so if you start using them in places they were not meant to go, for things they were not meant to do - you're begging for trouble. Oh yeah - and don't forget that all signed keys expire every year, most keys (whether or not signed) expire every few years, and you can't ever get a key without it coming inside a certificate, and these things can change all the time. Not my ideal concept of anything that's supposed to be "persistent". Oh - and the obvious thing while I'm here - nobody's got public keys anyhow, with the exception of a few geeks here and there, and everyone involved in cybercrime. Kind Regards, Chris Drake, =1id.com Wednesday, June 6, 2007, 2:50:17 PM, you wrote: dr> For posterity, here's how I'd summarize this thread about using public keys dr> as persistent identifiers: dr> 1) Yes, a public key could be used as an identifier, and could serve as a dr> persistent identifier if it was not reassignable. dr> 2) The issue of it becoming invalid as a credential if the private key was dr> compromised is orthogonal to its use purely as an identifier, i.e., as dr> Johannes points out, if the private key was compromised, use of the public dr> key could revert to the role of serving purely as an identifier, and another dr> set of credentials (such as another public/private key pair) could be dr> assigned. dr> 3) In this light, the primary drawbacks I see to public keys as identifiers dr> are: dr> a) They are typically much larger than other persistent identifiers dr> designed for this purpose (e.g., XRI i-numbers as issued by XDI.org or dr> Handles as issued by CNRI). dr> b) I am not aware of a resolution protocol designed for them, with dr> the exception that I believe syntactially they could be used as XRI dr> i-numbers. dr> =Drummond dr> -Original Message- dr> From: [EMAIL PROTECTED] dr> [mailto:[EMAIL PROTECTED] On Behalf dr> Of Johannes Ernst dr> Sent: Tuesday, June 05, 2007 7:27 PM dr> To: =nat dr> Cc: 'OpenID specs list' dr> Subject: Re: Specifying identifier recycling dr> I think you are making an invalid analogy. What prevents you from dr> setting up a "private key reset" function the same way you set up a dr> "password reset" function, using an alternate credential? You allow dr> for this for non-public-key credentials but not for others ... dr> But I don't want to perpetuate this thread given the general dr> reluctance of the community to think about public key cryptography at dr> this time ... I just want to go on record that I find the arguments dr> made counter public keys on this thread non-persuasive and want to dr> pick it back up when the community is ready to go there ... (note dr> also that the security industry would not exist in the shape it does dr> if we didn't have public key crypto, so that technology does dr> contribute something somewhere ... perhaps also to OpenID?) dr> Just follow the following argument ... let's assume that the problem dr> that started this thread dr> ... can be solved by adding a number to the URL identifier (using a dr> fragment syntax or an i-number or whatever other approaches were dr> discussed) dr> ... then it also can be solved by adding a large number instead of dr> just any number dr> ... then it also can be solved by adding a large number that could be dr> a public key, which is nothing but a large number dr> ... which, therefore, makes a public-key-based approach at least as dr> powerful as a plain number dr> Just some stuff for thought ... ;-) dr> Cheers, dr> Johannes. dr> On Jun 5, 2007, at 17:58, =nat wrote: >> Hi. >> >> Ok. Now I see the heart of the topic :-) >> >> Fundamental difference is that you postulate that one cannot lose >> one's >> credential including all the information that bears onto establish >> one's >> identity while I do not postulate so. >> >> For example, one can loose one's password and reset it. >> You can loose your credit card and replace it. >> Doing so has not nullished your "identity". You still are yourself. >>
Re[3]: Server-to-server channel
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 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. Imagine, instead, the exact same thing occurs on a web site, instead of at a newsagent. Nobody even blinks when this gross misuse of *my* information actually does occur. I would go as far as to say that opinions contrary to mine about "how the world (internet) should be" are in fact the "bizarre" ones!! --- My suggestion for how an OP might choose to present the kinds of data-protection defaults users might want would be for the OP to have a set of "per-user global account preferences". Mum and Dad users can click the "convenient" radiobutton. Political activists can click the "strong protection" radiobutton. Folks inbetween can be given middle-road defaults, and/or anyone can be given per-use overrides. Whichever OPs (or OP software packages that you choose to download and run yourself) that do these things the best, should then quite quickly become the market leaders. As long as the protocol supports the protection, the market can innovatively offer it. The challenges I see at present, are these: 1. How should an RP advertise to an OP what it's server-to-server endpoint is. 2. How should an OP advertise to an RP the same thing. 3. How should an RP indicate to user-agents (eg: browser plugins like SSO enablers, secure chrome/anti-phishing/anti-virus addons, form-fillers, OP helpers [or even OP software itself, if running on an end-users home machine]) that it is an "OpenID 2.0" enabled service in the first place. I've pushed for this to be standardized and enforced, because it offers the absolute strongest future support for new technologies - and I do so again now. If my web browser, upon visiting www.example.com, can immediately detect that it's an OpenID 2.0 site (eg: through a tag on every page, or the root or base URL, or HTTP headers, or whatever) - a massive pile of cool opportunities all spring up to make "Web 2.0" *seriously* more compelling, useful, and protective for everyone. Heck - Cardspace already did this - so we don't even have to argue the merits: They learned the long, hard, and painful way that excluding the user agent seriously undermines the trust and usefuln
Re[2]: Server-to-server channel
Thursday, April 5, 2007, 5:43:02 AM, you wrote: [snip] DO> How these keys are handled internally could be left to the DO> consumer or RP. [snip] This sounds like another *strong* use-case for updating the OpenID protocol to allow transactions to take place when the user is not present. I am not likely to be present when people relying upon my certificates choose to verify signatures, check for revocation, or attempt to encrypt stuff destined for me. There needs to be a way for the RP to contact my OP and get access to my information (eg: my current public key and revocation list) - by my explicit prior consent of course. I believe it's entirely unreasonable, and privacy-invasive, and identity-theft-dangering, to expect every RP out there to have to cache a copy of all my credentials, and for me or my OP to have to propagate any changes/updates/addition etc out to them all. Keeping all my info in one place solves this - only if the RPs can get what they want, *when* they want, which can't be done without server-to-server means. Chris. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: Server-to-server channel
Thursday, April 5, 2007, 3:50:49 AM, Martin wrote: MA> 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. >> MA> I think you're kidding yourself if you believe that RP's won't cache the MA> information they obtain. True - we may not always be able to force some RPs to not violate our trust. This is not, in my opinion, a justification for preventing any IP from acting in a trustworthy way, and definitely not a justification to deny users the opportunity (by omitting the mechanism from the protocol) to select RPs who claim not to cache information. 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. 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. 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" 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. When a rogue RP violates your trust and caches data without your permission, that's bad. When you choose not to specify a server-to-server channel, you're forcing *every* RP to behave in exactly the way that your theoretical rouge RP might have done. What's a bigger mistake? Having a few bad apples, or having no apples at all? Chris. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: Server-to-server channel
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. Kind Regards, Chris Drake Wednesday, April 4, 2007, 5:45:55 PM, you wrote: MA> Anders Feder wrote: >> >> Imagine an RP requesting your bank account number X from your OP. Time >> goes by, and your OP goes out of business. Later, you switch banks and >> your account number X is assigned to someone else. In the meantime, the >> RP has been preparing a payment for a job you have done for them. The RP >> look up your account number in its database, and see X. And since the RP >> has not received any updates to your bank account information, it >> reasons that your account number is still X and consequently disburse >> your payment on a stranger's account ... >> MA> information is old, then the RP would presumably be hesitant to act on MA> it without verification. MA> What constitutes "old" information depends on the attribute... things MA> like "Full Name" are, for many people, changed never or at most once in MA> their lives. However, things like a credit card number tend to change MA> every few years as cards expire. MA> Some information has a built-in expiry date (such as credit card MA> details), while other information just has a "likelyhood of change". MA> This implies to me that the following three things are needed: MA> * The possibility of a hard expiry date on a particular piece of MA> information. MA> * "soft" expiry dates which are more like "refresh this every n MA> months", where the RP gets less and less convinced about the accuracy of MA> the data as it ages, but may continue to use it for some time even when MA> it's "a bit old". MA> * The ability for an RP to request a refresh of attributes it stores MA> without necessarily including the user in the transaction. (The user MA> presumably will have made approval/revoking decisions out of band at an MA> earlier time.) MA> ___ MA> specs mailing list MA> specs@openid.net MA> http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: Server-to-server channel
Hi All, Since it's a lot easier to just put a server-to-server mechanism in place, than it is to argue about what it should be used for - can we perhaps instead attempt to agree that server-to-server is going to be something potentially useful in at least some cases, and go ahead and specify it? I believe there is a good use case for my OP (that I have chosen to trust as the gatekeeper to all my personal information) being allowed to store my data, arbitrate (server-to-server) access to it, and propagate (server-to-server) updates. This isn't complicated - HTTPS transport over existing endpoints is sufficient. Wednesday, April 4, 2007, 9:06:49 AM, Anders Feder wrote: >... Currently, if my OP turns rogue or otherwise fail to serve me... The idea that OP's might turn hostile, and that RP's are more trustworthy seems completely backwards to me. When I choose an OP (or I download and run my own), I'll take trust, reputation, and safety into account. When I choose all my RP's, I'll essentially ignore trust, reputation, and safety because I've already chosen my OP to handle all this for me. It's also safer to trust one OP, than it is to trust (for example) all 100 RPs I've used. And that's not even *starting* on the fact that I can change my OP away from any rogue one any time I want anyhow... I can understand that folks involved with RPs and associated development will be horrified at the idea of giving their users control of their information. If I was an RP, I would not like to let my customers revoke my access to their details: I'm going to want my hypothetical RP to spam them indefinitely, continue to charge their credit card long after they've gone, sell their details to marketing companies, count them as "active users" when I try to sell my RP to google, provide their address to snail-mail campaigners or police, send unsolicited text messages to their mobile phones, plunder their data to retaliate against them when I find them saying nasty things about my RP in public, and so forth. Every now and then, some RPs might even violate user trust and secretly store user "OP-Only" information without permission: the RP will be easily named and shamed when they're "found out" - which they will easily be, as soon as a user revokes access and then (for example) discovers the RP still sent them spam. Here's some things I want to do, but that OpenID does not currently support - but could with server-to-server support: 1. 1-click, or zero-click Single-Sign-On (no typing) 2. Single-Sign-Off 3. "User-Centricity" (This is in "quotes" because I define this as "Giving ME full control of MY information") A) propagating changes to my info out to RPs B) revoking access to my info at RPs C) auditing the usage of my info by RPs D) access authorization ( SAML+X-GTRBAC / XACML ) eg: facilitating grants by 3rd parties allowing users to access RP facilities (eg: data that RP cannot physically store) E) identity protection 4. Other: I'm not the only one who's looking to implement facilities that require more than just a browser-transported, user-present OpenID interaction. All server-to-server comms will be properly secured and authenticated (ie: no old/rogue/non-authorative OP will be able to influence any RP) Kind Regards, Chris Drake ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Spec suggestion: Appendix A.4. HTML Identifier Markup: livejournal replacement
Hi, I'd like to see the "livejournal" examples replaced with ones from somewhere that actually supports 2.0 and XRI's - it's very confusing to pop over to livejournal and find that nothing works properly... Kind Regards, Chris Drake ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Server-to-server channel
Hi, I've been away a while - is there any server-to-server mechanism built into OpenID yet? I've noticed folks wanting to build a "log off" facility for OpenID, which essentially requires the users server to inform whatever places the user has been recently to "drop" any session info. I've also noticed a lot of discussion about attributes, which begs the question about how to handle things that change (eg: If I've given out my email address to a dozen web sites, and then I change it, how does my OpenID server propagate that change to all those sites?) "User Centric" implies that sites don't store anything about me, and that whenever they need to know stuff (eg: my email), they instead ask my OpenID server, which returns them the answer (unless I've since revoked permission or whatever). Again - server-to-server (although this time in the reverse direction) applies here. Many months ago, I proposed the idea of "Single Sign On" - which is defined as letting a user access one or more web sites in some short period of time, without that user having to type anything in (not their password, not their username/email, not even their giant long identity URL), and while letting that user click just once (or preferably zero times - that is - they're auto-magically "single signed on" as soon as they re-visit the next different OpenID-compatible web site for the day) to "get in". server-to-server is again required to accomplish this user-friendly functionality. Since I've been offline, I'm confident that there have been more use cases for server-to-server proposed by other people as well. Is there any way for providers and consumers to identify one-anothers endpoints yet (in the "absence" of the user's browser as a transport mechanism), and for attributes etc to be exchanged between? Kind Regards, Chris Drake ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[6]: OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID Form Clarification (A.4))
Hi Johannes, Yep - that's right. "Browser++" might also be an identity provision service (eg: web site), or combination of service and browser component. Component will need to be a browser plugin with access to the source of the page, and opportunity to enact changes to it (eg: fill in the username), which will mean it probably supplies JavaScript extensions into the page itself. Your items 2, 3, 4, and 5 may also all be "grouped" into a single automatic response in the case where a user has elected "single sign on". Kind Regards, Chris Drake Sunday, October 22, 2006, 9:03:30 AM, you wrote: JE> Chris, thanks for the answer, but I'm afraid I'm just as confused as JE> before. I think I don't understand your scenario. So: JE> 1) User navigates to a relying party JE> 2) Browser++ (i.e. browser with some kind of extension) detects the JE> fact that this a relying party (and the means by which that occurs is JE> the subject of this discussion) JE> 3) Browser++ shows some kind of user interface that's implemented by JE> the browser++ instead of the relying party for identity selection etc. JE> 4) User fills out whatever needs filling out / approving etc. in the JE> browser++ user interface JE> 5) Browser++ submits (e..g HTTP POST) to relying party at the right URL JE> Did I get this right? I must be missing something, though, given the JE> constraints you are listing? JE> On Oct 21, 2006, at 8:17, Chris Drake wrote: >> Hi Johannes, >> >> JavaScript can't talk Yadis, cannot maintain "state" between pages, >> and is highly likely to be blocked from external resources by >> cross-site-scripting security restrictions. Even if it could go out >> and resolve the OpenID info it needs from external resources, it would >> halve the loading speed of every page involved. >> >> We should not ignore the opportunities that Identity 2.0 is presenting >> to OpenID, so we need to ensure that hooks put in place to enable >> Identity systems to use OpenID are added in a useable way. >> >> Kind Regards, >> Chris Drake >> >> >> Friday, October 20, 2006, 3:03:25 PM, you wrote: >> >> JE> Chris, I'm a little slow here, please bear with me. What's the >> JE> reasoning for "without accessing other resources"? >> >> JE> I am with you if you said "we can't ask a user agent to first do a >> JE> MIME type of XRDS". But what's the difference between adding a >> new ad- >> JE> hoc link tag in the HTML to the Yadis tag in the HTML or the HTTP >> JE> header? >> >> >> >> JE> On Oct 19, 2006, at 19:44, Chris Drake wrote: >> >>>> Hi Johannes, >>>> >>>> No - Yadis is inappropriate because user agents need to be able to >>>> identify an OpenID login page (and endpoint if possible) *without* >>>> accessing other resources. >>>> >>>> Kind Regards, >>>> Chris Drake >>>> >>>> >>>> Friday, October 20, 2006, 10:33:40 AM, you wrote: >>>> >>>> JE> Isn't this a case where the Yadis infrastructure should be used >>>> JE> instead of Yet Another Link Tag? >>>> >>>> >>>> JE> On Oct 19, 2006, at 8:21, Drummond Reed wrote: >>>> >>>>>> Martin, I agree with Dick, this is a fascinating idea. P3P had the >>>>>> same idea >>>>>> notion for a site advertising the location of the P3P privacy >>>>>> policy: it >>>>>> defined a standard HTML/XHTML link tag that could be put on any >>>>>> page of a >>>>>> site that told the browser where to locate the P3P policy document >>>>>> for the >>>>>> site (or for any portion of the site). >>>>>> >>>>>> http://www.w3.org/TR/P3P/#ref_syntax >>>>>> >>>>>> Are you proposing the same thing for OpenID login? >>>>>> >>>>>> (Kewl!) >>>>>> >>>>>> =Drummond >>>>>> >>>>>> -Original Message- >>>>>> From: [EMAIL PROTECTED] >>>>>> [mailto:[EMAIL PROTECTED] On >>>>>> Behalf >>>>>> Of Dick Hardt >>>>>> Sent: Thursday, October 19, 2006 12:53 AM >>>>>> To: Martin Atkins >>>>>> Cc: specs@openid.net >>>>>> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) >>>
Re[4]: OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID Form Clarification (A.4))
Hi Johannes, JavaScript can't talk Yadis, cannot maintain "state" between pages, and is highly likely to be blocked from external resources by cross-site-scripting security restrictions. Even if it could go out and resolve the OpenID info it needs from external resources, it would halve the loading speed of every page involved. We should not ignore the opportunities that Identity 2.0 is presenting to OpenID, so we need to ensure that hooks put in place to enable Identity systems to use OpenID are added in a useable way. Kind Regards, Chris Drake Friday, October 20, 2006, 3:03:25 PM, you wrote: JE> Chris, I'm a little slow here, please bear with me. What's the JE> reasoning for "without accessing other resources"? JE> I am with you if you said "we can't ask a user agent to first do a JE> MIME type of XRDS". But what's the difference between adding a new ad- JE> hoc link tag in the HTML to the Yadis tag in the HTML or the HTTP JE> header? JE> On Oct 19, 2006, at 19:44, Chris Drake wrote: >> Hi Johannes, >> >> No - Yadis is inappropriate because user agents need to be able to >> identify an OpenID login page (and endpoint if possible) *without* >> accessing other resources. >> >> Kind Regards, >> Chris Drake >> >> >> Friday, October 20, 2006, 10:33:40 AM, you wrote: >> >> JE> Isn't this a case where the Yadis infrastructure should be used >> JE> instead of Yet Another Link Tag? >> >> >> JE> On Oct 19, 2006, at 8:21, Drummond Reed wrote: >> >>>> Martin, I agree with Dick, this is a fascinating idea. P3P had the >>>> same idea >>>> notion for a site advertising the location of the P3P privacy >>>> policy: it >>>> defined a standard HTML/XHTML link tag that could be put on any >>>> page of a >>>> site that told the browser where to locate the P3P policy document >>>> for the >>>> site (or for any portion of the site). >>>> >>>>http://www.w3.org/TR/P3P/#ref_syntax >>>> >>>> Are you proposing the same thing for OpenID login? >>>> >>>> (Kewl!) >>>> >>>> =Drummond >>>> >>>> -Original Message- >>>> From: [EMAIL PROTECTED] >>>> [mailto:[EMAIL PROTECTED] On >>>> Behalf >>>> Of Dick Hardt >>>> Sent: Thursday, October 19, 2006 12:53 AM >>>> To: Martin Atkins >>>> Cc: specs@openid.net >>>> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) >>>> >>>> >>>> On 19-Oct-06, at 12:35 AM, Martin Atkins wrote: >>>> >>>>> Dick Hardt wrote: >>>>>> >>>>>> In order for the RUA to detect that a site supports OpenID, it >>>>>> sees a >>>>>> form with a single input with a "name" of openid_identiifier. The >>>>>> RUA >>>>>> can then look at the action and post the data directly to the RP. >>>>>> >>>>> >>>>> I think it'd be better to implement this as either a META or a LINK >>>>> element alongside a standard protocol for communicating with the >>>>> nominated URL. >>>>> >>>>> This way the site can declare on *all pages*, rather than on the >>>>> forms-based login page, that it accepts OpenID auth. This allows >>>>> the >>>>> user to go to the RP's home page (or any other page) and click the >>>>> "OpenID Login" button on the browser's toolbar and have it work. >>>> >>>> That is an interesting idea. Would you like to take a stab at more >>>> specifics? >>>> >>>> -- Dick >>>> ___ >>>> specs mailing list >>>> specs@openid.net >>>> http://openid.net/mailman/listinfo/specs >>>> >>>> ___ >>>> specs mailing list >>>> specs@openid.net >>>> http://openid.net/mailman/listinfo/specs >> >> JE> Johannes Ernst >> JE> NetMesh Inc. >> >> >> JE> Johannes Ernst JE> NetMesh Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID Form Clarification (A.4))
Hi Johannes, No - Yadis is inappropriate because user agents need to be able to identify an OpenID login page (and endpoint if possible) *without* accessing other resources. Kind Regards, Chris Drake Friday, October 20, 2006, 10:33:40 AM, you wrote: JE> Isn't this a case where the Yadis infrastructure should be used JE> instead of Yet Another Link Tag? JE> On Oct 19, 2006, at 8:21, Drummond Reed wrote: >> Martin, I agree with Dick, this is a fascinating idea. P3P had the >> same idea >> notion for a site advertising the location of the P3P privacy >> policy: it >> defined a standard HTML/XHTML link tag that could be put on any >> page of a >> site that told the browser where to locate the P3P policy document >> for the >> site (or for any portion of the site). >> >> http://www.w3.org/TR/P3P/#ref_syntax >> >> Are you proposing the same thing for OpenID login? >> >> (Kewl!) >> >> =Drummond >> >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On >> Behalf >> Of Dick Hardt >> Sent: Thursday, October 19, 2006 12:53 AM >> To: Martin Atkins >> Cc: specs@openid.net >> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) >> >> >> On 19-Oct-06, at 12:35 AM, Martin Atkins wrote: >> >>> Dick Hardt wrote: >>>> >>>> In order for the RUA to detect that a site supports OpenID, it >>>> sees a >>>> form with a single input with a "name" of openid_identiifier. The >>>> RUA >>>> can then look at the action and post the data directly to the RP. >>>> >>> >>> I think it'd be better to implement this as either a META or a LINK >>> element alongside a standard protocol for communicating with the >>> nominated URL. >>> >>> This way the site can declare on *all pages*, rather than on the >>> forms-based login page, that it accepts OpenID auth. This allows the >>> user to go to the RP's home page (or any other page) and click the >>> "OpenID Login" button on the browser's toolbar and have it work. >> >> That is an interesting idea. Would you like to take a stab at more >> specifics? >> >> -- Dick >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs >> >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs JE> Johannes Ernst JE> NetMesh Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: PROPOSAL: OpenID Form Clarification (A.4)
Hi David, Besides other DIX lurkers, we know for sure that Dick, Andy, and myself are all building "chrome" extensions and/or rich-clients, so I think you'll have no problems getting a "consensus" on this. My personal vote is for something like this:- http://my.rp.com/openid/blah.cgi";> either on the page with the login , or even every page on an OpenID 2.0 enabled site. Browser agents and IdP's alike can use this information not just for facilitating chrome etc, but also for privacy protection, *true* single-signon, identifier selection, and a range of other things. Kind Regards, Chris Drake Thursday, October 19, 2006, 3:33:31 PM, you wrote: RD> This isn't worth me standing in the way. If you can get general RD> consensus of those actively participating in the spec process then I RD> won't stand in the way of the community, in fact if this happens I'd be RD> happy to make the change to the spec. RD> There seems to be other ways to deal with this though, since you're RD> going to have to deal with the case of a RP not having this markup. RD> Giving the rich client an icon like the SSL padlock which lights up when RD> the user visits a RP that supports it and then the user clicking it, or RD> submitting the form, to start the flow seems like one viable entry RD> point. To deal with a RP with no markup, the user would not see the RD> icon illuminate, position their cursor within the OpenID field, and then RD> click the icon which would indicate to the client that this actually is RD> a RP as well as let it capture the field within the DOM to interact RD> with. RD> --David RD> -Original Message- RD> From: Dick Hardt [mailto:[EMAIL PROTECTED] RD> Sent: Thursday, October 19, 2006 1:04 AM RD> To: Recordon, David RD> Cc: Jonathan Daugherty; specs@openid.net RD> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) RD> Unfortunate that was not captured in the notes. When I said that we RD> needed tags to detect, there was consensus that was not a problem. RD> We are building a rich client. It will be available in the not-too- RD> distant-future. RD> We are working on what it will take to implement, and have figured out RD> how to make it all work, but need to detect that the site is an RP. RD> Lack of clarity on what MUST happen adding many, many lines of code to RD> the early browsers. It would be good to not repeat that mistake. RD> I really don't see how making this a MUST instead of SHOULD would slow RD> specs or implementation as I am sure most people will just do it anyway. RD> I've made my case and will let it rest. RD> -- Dick RD> On 18-Oct-06, at 9:55 PM, Recordon, David wrote: >> Here are notes from the June meeting, which we all looked over before >> I sent them out. All I see in relation to rich clients is that DIX >> supported them, though I don't remember any decision being made that a >> requirement of OpenID Authentication was every relying party enabling >> the use of a rich client. >> http://lists.danga.com/pipermail/yadis/2006-June/002648.html >> >> I don't think this should be a MUST as it adds one more requirement >> which we can't even effectively enforce. If/when rich client software >> gets out there and is being actively used, I'd be much more inclined >> to change this to a MUST. Right now I think we should just get this >> spec done, get people using it, and see what develops and thus how it >> needs to evolve! >> >> --David >> >> -Original Message- >> From: Dick Hardt [mailto:[EMAIL PROTECTED] >> Sent: Thursday, October 19, 2006 12:44 AM >> To: Recordon, David >> Cc: Jonathan Daugherty; specs@openid.net >> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) >> >> That is news to me that supporting Rich Clients is not a requirement. >> Rich client support was a discussion point back in July at the meeting >> in VeriSign, and there was consensus to support Rich Clients then >> >> Would you point me to the list of requirements so that we can all get >> on the same page on what they are? >> >> I am really confused why you would not want this to be a MUST. >> >> -- Dick >> >> On 18-Oct-06, at 9:35 PM, Recordon, David wrote: >> >>> The spec is an authentication spec which does not discuss rich >>> clients >> >>> anywhere. >>> >>> As I've said, and I'd think others would agree, it is not a >>> requirement of the spec to enable rich clients. It is great to have >>> them and great for it to enable them. Whether the spec says this is >>>
Re[2]: PROPOSAL: OpenID Form Clarification (A.4)
Hi Jonathan, I vote for MUST. The opinion of unenforcability isn't a justification for SHOULD, and I disagree with that opinion anyhow: we already know that browser-chrome plugins will be supporting OpenID - as soon as an RP picks some other field name, he'll get a flood of complains from users who can't log in to his site. Kind Regards, Chris Drake Thursday, October 19, 2006, 5:27:02 PM, you wrote: JD> # Why SHOULD rather then MUST? [1] JD> # JD> # What valid reason is there for an RP to not have that field name? JD> The simple reason is that one can't enforce a MUST in this case. (And JD> even if one ammends the spec to make the field name a prerequisite for JD> OpenID, I question whether that is a good design choice.) JD> I agree that it would be extremely useful to have a consistent form JD> field name for just the reasons you cited, and the current spec JD> reflects that. If the spec is the place one would put preferences, JD> then they should be RECOMMENDEDs or SHOULDs: not MUSTs. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: [dix] Re: Gathering requirements for in-browser OpenID support
Hi Scott, All solutions for client-based MITM and phishing prevention can easily be built on top of OpenID 2.0 if we adopt the OpenIDHTTPAuth proposal. We can then leave these people to build their tools and protection howsoever they like, safe in the knowledge that when it's *done*, there will be a range of new plugins that will immediately work with all OpenID 2.0 enabled sites - and best of all - it does not have to hold up the OpenID 2.0 development in the meantime. The only thing we need to give to these tools is a way to get the login process started - that is - OpenIDHTTPAuth: the downloaded plugin needs to be able to get an entry point for the OpenID CGI code on the web site. --- Here is a copy of my vote to include the above proposal, which contains more info abut it too: Hi, Why's this proposal "depreciated" ? ( http://www.lifewiki.net/openid/OpenIDProposals ) I'm casting my vote here: +1 to [PROPOSAL] bare response / bare request Besides the listed uses, it also allows IdPs to layer privacy and delegation easily on top of OpenID, as well as permitting cool future features (like letting a user change something at their IdP, and have that change be "pushed out" to all relevant RPs). This is a small and simple to implement "hook" which I believe will be the dominating bit of OpenID protocol use in future. Alternatively - if we can standardize a way for the OpenIDHTTPAuth proposed extension to discover the RP's OpenID "entry point" [so as to reliably eliminate the "optional" first step proposed here http://www.lifewiki.net/openid/OpenIDHTTPAuth ] - this is a good working alterative way to accommodate the "bare response" part that we need. So... +1 to OpenIDHTTPAuth - on the proviso RP's publish an endpoint URL that's somehow available to scripts, plugins, software agents that encounter OpenID login pages. Suggestion: (for OpenID-enabled login pages):- http://my.rp.com/openid/blah.cgi";> --- Kind Regards, Chris Drake Thursday, October 19, 2006, 6:07:08 AM: >> It is vulnerable to a man in the middle attack - the RP, instead of >> redirecting to the IdP redirects to itself or some other site in >> cahoots, then proxies the conversation between the user and the IdP >> thereby compromising the users (global) credentials as they pass through. SK> Right, we've known about this for quite some time unfortunately there hasn't SK> be a particularly easy solution to it and I classify this as one of those SK> "The Internet Sucks" problems. I'm not saying we shouldn't/couldn't do SK> anything about it I just think the right solution that mixes SK> ease-of-implementation and user need hasn't been found yet. >> There really needs to be user-agent support to avoid that - either >> something CardSpace like, or browser plugin that only ever presents a >> pre-authenticated user. SK> I think we're headed in this direction. However, we have to crawl before we SK> can walk. At least solving a big chunk of the use cases, getting some SK> momentum behind the platform and solving a specific problem for users SK> *today* is better than trying to build the perfect tool. We can talk and SK> talk on these lists but we really don't know how users are going to use this SK> stuff (or abuse it for that matter) until its out there and working in the SK> wild. SK> I can't emphasize more the fact that with every passing day that we don't SK> have OpenID v2.0 out the door, we're losing momentum from fixing specific SK> user problems that are solved in the existing specification. SK> - Scott SK> ___ SK> general mailing list SK> [EMAIL PROTECTED] SK> http://openid.net/mailman/listinfo/general ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: pre announce: Java and Perl libraries
Hi Guys, Please remember to make your Perl code run in "taint" mode; If you're having problems or not sure what that is - I'm happy to help out. Kind Regards, Chris Drake Thursday, October 19, 2006, 12:34:35 AM, you wrote: RD> Dick, RD> Good news, but I guess I already knew about this. :P RD> Will Sxip be contributing these libraries to the Heraldry project RD> (http://incubator.apache.org/projects/heraldry.html) like JanRain has RD> already done with their 1.1 libraries, intends to do with their 2.0 RD> libraries, and VeriSign has done with our IdP? I'd be happy to help RD> facilitate your developers getting the needed accounts within the Apache RD> Software Foundation to make this happen. RD> --David RD> -Original Message- RD> From: [EMAIL PROTECTED] RD> [mailto:[EMAIL PROTECTED] On RD> Behalf Of Dick Hardt RD> Sent: Wednesday, October 18, 2006 2:10 AM RD> To: specs@openid.net; [EMAIL PROTECTED] RD> Subject: pre announce: Java and Perl libraries RD> Hey Lists RD> We realized in a meeting today that we had talked to some people in the RD> community, but had never made a formal statement. RD> Sxip is writing and will be releasing Java and Perl libraries for OpenID RD> 2.0 under an Apache license. RD> You should see them shortly after the spec is finished, assuming nothing RD> significant happens to the spec between now and then. The Java and Perl RD> libraries will also support OpenID Attribute Exchange. RD> -- Dick RD> ___ RD> general mailing list RD> [EMAIL PROTECTED] RD> http://openid.net/mailman/listinfo/general RD> ___ RD> specs mailing list RD> specs@openid.net RD> http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
[PROPOSAL] bare response / bare request
Hi, Why's this proposal "depreciated" ? ( http://www.lifewiki.net/openid/OpenIDProposals ) I'm casting my vote here: +1 to [PROPOSAL] bare response / bare request Besides the listed uses, it also allows IdPs to layer privacy and delegation easily on top of OpenID, as well as permitting cool future features (like letting a user change something at their IdP, and have that change be "pushed out" to all relevant RPs). This is a small and simple to implement "hook" which I believe will be the dominating bit of OpenID protocol use in future. Alternatively - if we can standardize a way for the OpenIDHTTPAuth proposed extension to discover the RP's OpenID "entry point" [so as to reliably eliminate the "optional" first step proposed here http://www.lifewiki.net/openid/OpenIDHTTPAuth ] - this is a good working alterative way to accommodate the "bare response" part that we need. So... +1 to OpenIDHTTPAuth - on the proviso RP's publish an endpoint URL that's somehow available to scripts, plugins, software agents that encounter OpenID login pages. Suggestion: (for OpenID-enabled login pages):- http://my.rp.com/openid/blah.cgi";> Kind Regards, Chris Drake Saturday, October 7, 2006, 9:52:36 AM, you wrote: KT> On Fri, 2006-10-06 at 16:34 -0700, Drummond Reed wrote: >> Let me play the dumb customer here and say: >> >> * A whole lot of real-world users would love OpenID-enabled bookmarks. >> * A whole lot of websites would love to offer them. >> * A whole lot of IdPs would love to provide them. KT> Okay Customer, if both websites and IdPs would love it, is it okay if KT> it's something that websites + IdPs can layer on top of the core? If KT> some sites chose not to, and the IdP said "login bookmark not available KT> for this site", would that be okay? KT> ___ KT> specs mailing list KT> specs@openid.net KT> http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[4]: Identifier portability: the fundamental issue
Hi Drummond, Yikes! - sorry about the misquote - very clumsy of me. Kind Regards, Chris Drake ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: Identifier portability: the fundamental issue
Hi Drummond, DR> ... if there is any record at all of any association between these DR> two identities, ... double-blind anonymous authentication solves this problem. The RP knows nothing more about you besides: A) you're authenticated, and/or B) you've been here before (eg: have signed up for an account) The IdP knows merely C) That you wanted to log in somewhere The RP does not know your ID or even your IdP, and your IdP does not know what site you logged in to. I have a working proof-of-concept that I demonstrated to a few people some months back, let me know if you've not seen it, and I'll send over the URL In a nutshell - this relies on uniform "nonce" formats and asymmetric cryptography (so the RP and IdP can "talk" between one another without making any actual contact - the browser and/or user "carry" the authentication payloads forth and back without referrer URLs or any other info that can link the 2 sites (RP/IdP) together). Besides all that - the normal "use case" for an IdP in OpenID world (remember: decentralized) will be someone running some open-source code on their own server, so trust in this instance *is* boolean: at least in so far as if there's anything for someone to not be trustworthy about themselves for - it won't be the fault of their IdP code PROVIDING their IdP has provided them with IdP-initiated logins in order to allow this user to protect their own privacy in the first place. Court orders are what I termed "3.5. Authorized exploitation" in my threat list, and "insider leaks" I called "1.3.6. physical attack of server resources (eg: server/hosting-facility compromise)" - there's another 98 other threats to keep in mind here as well:- http://chrisdrake.com/Comprehensive_list_of_Threats_to_Authentication_Procedures_and_Data.html While your example might seem extreme, the consequences are also extreme (or fatal, if you live someplace like China) - which is why I take privacy so seriously. Stick "Himalayas video" into google news if you want to watch what Chinese do to their own people when found trying to visit the Dalai Lama. Now - how comfortable are you with the idea of letting 1.5 billion Chinese people use OpenID without making it easy to help them protect their own privacy ? There's a big picture here, and it's not about meeting some arbitrary deadline or saving a day or two of coding work - it's about producing something that works, and can be deployed ethically. Take a long hard look at that Nun lying dead in the snow, then tell me you still believe there's no need for IdP-initiated privacy protection in OpenID. Kind Regards, Chris Drake, =1id.com Tuesday, October 17, 2006, 7:29:00 AM, you wrote: DR> +1. "Trust is not a boolean." Martin, that's very quotable. Can I attribute DR> it to you? DR> =Drummond DR> -Original Message- DR> From: [EMAIL PROTECTED] DR> [mailto:[EMAIL PROTECTED] On Behalf DR> Of Martin Atkins DR> Sent: Monday, October 16, 2006 12:25 PM DR> To: specs@openid.net DR> Subject: Re: Identifier portability: the fundamental issue DR> 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. >> DR> If I'm using one IdP to assert my primary public identity, they can DR> hypothetically develop quite a profile about me. I probably don't mind DR> too much in most cases, because I researched them and found that they DR> are a good provider and won't sell my data out to the bad guys. DR> However, there might be some things I want to do (for example, posting DR> locally-prohibited speech on a public forum) that I don't want attached DR> in any way, shape or form to my public identity. The trust relationship DR> I have with that IdP probably isn't enough for this; if there is any DR> record at all of any association between these two identities, as DR> friendly as my IdP may be, there is a chance that it will be ceased by DR> court order, or leaked by an insider, which might lead to me getting in DR> serious legal trouble. DR> This is just one (perhaps extreme) example of why my trust in my IdP is DR> not universal and all-encompassing. Trust is not a boolean. DR> ___ DR> specs mailing list DR> specs@openid.net DR> http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Summarizing Where We're At
Hi David, What is the rush for? There's a lot of unhappy people here due to missing protocol elements. I for one believe the lack of privacy considerations is an entire OpenID "killer". Is there a reason why you've omitted my IdP-initiated login proposal from your short list (also known as "bookmark login url discovery")? If you're not convinced of the importance of privacy - read your own IdP home page: http://pip.verisignlabs.com/ " Verify your identity without compromising your privacy with PIP, the personal identity management system from VeriSign. " Verisign chose Privacy as *the* most important and critical feature that their IdP should support - does your PIP service plan to *use* OpenID, and if so, how do you propose to handle privacy problems (eg: RP's collaborating about users behind their backs) ? Imposing an arbitrary time limit will result in an incomplete spec. Kind Regards, Chris Drake Monday, October 16, 2006, 5:28:52 AM, you wrote: RD> So previously I had set the goal of the final draft coming out last RD> Friday, though we've missed that. I'm resetting this bar to Wednesday RD> which means we need to wrap up discussion on proposals where there is RD> general consensus as well as accept that some proposals will not make it RD> into this version. For all proposals, unless there is general consensus RD> they should be included by Tuesday evening they will not be included. RD> * Request Nonce and Name RD> - Has been partially implemented, openid.nonce -> RD> openid.response_nonce, no agreement on the need of a request nonce RD> specifically, rather discussion has evolved into allowing a RP to pass RD> "appdata" like in Yahoo's BBAuth. No formal proposal on the table yet, RD> thus will not be included in this version. RD> * Authentication Age RD> - Re-proposed today adding clarity in motivation, general consensus is RD> needed to add to specification. RD> * Remove setup_url RD> - Little discussion and no general consensus to do so. Rather seems RD> asking for feedback from checkid_immediate implementers on the parameter RD> would be beneficial at this time. RD> * Consolidated Delegation Proposal RD> - Very active discussion, the only proposal I'm willing to stall the RD> spec for. Seems very important a strong conceptual model is created at RD> this time. RD> * Change Default session_type RD> - Proposed, no discussion yet. RD> * Bare Request RD> - Proposed, no discussion yet. RD> I also feel strongly that no new proposals, except to update existing RD> ones, should be considered for inclusion in this version. RD> --David RD> ___ RD> specs mailing list RD> specs@openid.net RD> http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[4]: Discussion: RP Yadis URL?
Hi Dick, 1. IdP's "advertising" a list of sites that accept OpenID - like the way PayPal list stores that accept their currency I guess. It's annoying to a user to have to come back to the place they just clicked in order to click a second time in order to go where they wanted to in the first place... Better to send them where they want when they click the first time... 2. Privacy and delegation: if we force the user to initially interact with the RP, this gives the RP the opportunity to profile our users, start collecting (and sharing with other RPs) correlating information about them, and otherwise destroys IdP ability to protect user privacy. Basically - this comes back to your "Discussion: bookmark login url discovery" message - and for the sake of additionally supporting future security enhancements (eg: anti-phishing), I'd recommend we place something inside the RP's login page, like a or tag, for browser agents to use, or IdPs to find via referrer URLs. Kind Regards, Chris Drake Monday, October 16, 2006, 3:36:53 AM, you wrote: DH> Hi Chris DH> Would you clarify these IdP initiated scenarios? DH> I envisioned that an IdP learned of an RP from the user have an DH> initial interaction with the RP. The IdP would then save the RP URL DH> for later use in case the user wanted to go back to the RP directly DH> from the IdP. DH> -- Dick DH> On 15-Oct-06, at 10:30 AM, Chris Drake wrote: >> Hi Drummond, >> >> Don't forget we'll need some way for an IdP to discover the return_to >> URL from an RP in the IdP-initiated scenarios (I'd suggest a META or >> LINK tag in the web page that the RP displays for accepting a login, >> so an IdP (or browser plugin agent!) can "discover" this by parsing >> the referrer page directly. There's a lot of anti-phishing work >> taking place right now: such a scheme would allow OpenID instant >> access to these new standards too.) >> >> Kind Regards, >> Chris Drake >> >> >> Monday, October 16, 2006, 2:59:12 AM, you wrote: >> >> DR> +1. All of the "defined algorithms for obtaining the XRDS >> document" from >> DR> either a URL or XRI will be going into Working Draft 11 of XRI >> Resolution >> DR> 2.0 starting this week. So it seems all the OpenID >> Authentication 2.0 spec >> DR> needs to specify is that they work against the return_to URL. >> >> DR> =Drummond >> >> DR> -Original Message- >> DR> From: [EMAIL PROTECTED] >> DR> [mailto:[EMAIL PROTECTED] On Behalf >> DR> Of Johannes Ernst >> DR> Sent: Sunday, October 15, 2006 12:00 AM >> DR> To: specs@openid.net >> DR> Subject: Re: Discussion: RP Yadis URL? >> >> DR> Yes. Or any of the other defined algorithms for obtaining the XRDS >> DR> file, given the return_to URL. >> >> DR> On Oct 14, 2006, at 23:50, Dick Hardt wrote: >> >>>> I assume you are referring to the return_to URL? >>>> >>>> Current libraries add all kinds of parameters to that URL, would >>>> you be suggesting that the IdP does a GET on the return_to URL with >>>> content-type of XRDS? >>>> >>>> If so, then we should add that to the spec. I'd then like to get >>>> clear on what would need to be in the Yadis file for indicating the >>>> login_url. >>>> >>>> -- Dick >>>> >>>> On 14-Oct-06, at 11:43 PM, Johannes Ernst wrote: >>>> >>>>> Given that the RP has at least one URL, we can perform regular >>>>> Yadis discovery on it. (Likely, all of the RP's URLs point to the >>>>> same Yadis document.) >>>>> >>>>> I don't think an extension to the protocol is needed. >>>>> >>>>> On Oct 14, 2006, at 22:39, Dick Hardt wrote: >>>>> >>>>>> Currently there is no method for the IdP to learn anything >>>>>> about the >>>>>> RP. As a path for extensibility, would anyone have a problem with >>>>>> having an optional parameter in the AuthN Request for the >>>>>> location of >>>>>> the RP's Yadis document? >>>>>> >>>>>> -- Dick >>>>>> ___ >>>>>> specs mailing list >>>>>> specs@openid.net >>>>>> http://openid.net/mailman/listinfo/specs >>>>> >>>>> Johannes Ernst >>>>> NetMesh Inc. >>>>> >>>>> >>>>> http://netmesh.info/jernst >>>>> >>>>> >>>>> >>>>> >>>>> ___ >>>>> specs mailing list >>>>> specs@openid.net >>>>> http://openid.net/mailman/listinfo/specs >> >> DR> Johannes Ernst >> DR> NetMesh Inc. >> >> >> DR> ___ >> DR> specs mailing list >> DR> specs@openid.net >> DR> http://openid.net/mailman/listinfo/specs >> >> >> >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs >> >> ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: Discussion: RP Yadis URL?
Hi Drummond, Don't forget we'll need some way for an IdP to discover the return_to URL from an RP in the IdP-initiated scenarios (I'd suggest a META or LINK tag in the web page that the RP displays for accepting a login, so an IdP (or browser plugin agent!) can "discover" this by parsing the referrer page directly. There's a lot of anti-phishing work taking place right now: such a scheme would allow OpenID instant access to these new standards too.) Kind Regards, Chris Drake Monday, October 16, 2006, 2:59:12 AM, you wrote: DR> +1. All of the "defined algorithms for obtaining the XRDS document" from DR> either a URL or XRI will be going into Working Draft 11 of XRI Resolution DR> 2.0 starting this week. So it seems all the OpenID Authentication 2.0 spec DR> needs to specify is that they work against the return_to URL. DR> =Drummond DR> -Original Message- DR> From: [EMAIL PROTECTED] DR> [mailto:[EMAIL PROTECTED] On Behalf DR> Of Johannes Ernst DR> Sent: Sunday, October 15, 2006 12:00 AM DR> To: specs@openid.net DR> Subject: Re: Discussion: RP Yadis URL? DR> Yes. Or any of the other defined algorithms for obtaining the XRDS DR> file, given the return_to URL. DR> On Oct 14, 2006, at 23:50, Dick Hardt wrote: >> I assume you are referring to the return_to URL? >> >> Current libraries add all kinds of parameters to that URL, would >> you be suggesting that the IdP does a GET on the return_to URL with >> content-type of XRDS? >> >> If so, then we should add that to the spec. I'd then like to get >> clear on what would need to be in the Yadis file for indicating the >> login_url. >> >> -- Dick >> >> On 14-Oct-06, at 11:43 PM, Johannes Ernst wrote: >> >>> Given that the RP has at least one URL, we can perform regular >>> Yadis discovery on it. (Likely, all of the RP's URLs point to the >>> same Yadis document.) >>> >>> I don't think an extension to the protocol is needed. >>> >>> On Oct 14, 2006, at 22:39, Dick Hardt wrote: >>> >>>> Currently there is no method for the IdP to learn anything about the >>>> RP. As a path for extensibility, would anyone have a problem with >>>> having an optional parameter in the AuthN Request for the >>>> location of >>>> the RP's Yadis document? >>>> >>>> -- Dick >>>> ___ >>>> specs mailing list >>>> specs@openid.net >>>> http://openid.net/mailman/listinfo/specs >>> >>> Johannes Ernst >>> NetMesh Inc. >>> >>> >>> http://netmesh.info/jernst >>> >>> >>> >>> >>> ___ >>> specs mailing list >>> specs@openid.net >>> http://openid.net/mailman/listinfo/specs DR> Johannes Ernst DR> NetMesh Inc. DR> ___ DR> specs mailing list DR> specs@openid.net DR> http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: Identifier portability: the fundamental issue
Hi Josh, >> I do not believe the RP needs to know the IdP-specific identifier ever >> (worse: I think it should never be allowed to know it, or even be >> allowed to see it!). JH> Why not? PRIVACY. Page back and read trough my posts to this list for the intricate details. JH> Where is power being granted to the RP? It has pretty much none. JH> It *does* have responsibility, but only as much as is necessary to JH> make the protocol work. If RPs are allowed to build up linked portfolios of everyones identifiers, they can get together with other RPs (or sniff IDs in google) to snoop on and conspire against our users behind their backs. If the true spirit of OpenID is to empower users, it's seriously neglectful to block users from protecting their own privacy. >> Can we not adopt my earlier suggestion: just ensure OpenID can permit >> IdP-initiated logins. This permits every scenario of portability (and >> privacy) that everyone wants, without us having to continue to debate >> it ? JH> Huh? How is IdP-initiated login related to privacy or portability? It is ** NONE OF THE RPs BUSINESS ** how the OpenID that got presented to it was originally selected by, or resolved for, our Users. Letting the IdP initiate a login allows the IdP to PRIVATELY negotiate with the user over which identity to present (which for anyone who cares about privacy, will usually be a per-site identity not linked to their main OpenID or vanity domain or whathaveyou.). The beauty of this suggestion is that we don't even need to debate it: so long as IdP initiated logins are supported, market forces will then decide whether or not privacy and security become widespread in OpenID. I'm not saying this should be the *only* way an OpenID login can take place - just that if this simple concept is implemented, that we can then defer all privacy issues to the IdPs in future, and concentrate now on getting this spec out the door. -- I notice the current spec: http://openid.net/specs/openid-authentication-2_0-10.html does not even *mention* privacy? (besides the allusion in the abstract: "It does this without the Relying Party needing access to password, email address, or other sensitive information." - but somehow nobody's understanding that the users OpenID *itself* is "sensitive information", especially in the way google will in future let anyone troll back through our users online "tracks" using this ID...) Also missing are 16. Security Considerations and 16.1. Preventing Attacks Perhaps someone should add a section on privacy, and someone should take a crack at the security aspects! Who is in charge of writing this stuff? I've submitted 102 (one hundred and two!!!) security considerations in the posts I've made to this list so far: Shouldn't someone be documenting this? Chris. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
Hi Drummond, DR> CASE 1: the protocol supports only IdP-specific identifiers and no portable DR> identifiers. DR> RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1. Please explain? If I've got an OpenID URL (eg: my vanity domain), I can "transfer" this via DNS (or just update my OpenID ). If I've got an i-name, I can transfer this too. Where's the "lock in" ? I do not believe the RP needs to know the IdP-specific identifier ever (worse: I think it should never be allowed to know it, or even be allowed to see it!). Yes - we need 2 identifiers - but from the point of view of the specs - the OpenID protocol really only needs to deal with one. 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. Can we not adopt my earlier suggestion: just ensure OpenID can permit IdP-initiated logins. This permits every scenario of portability (and privacy) that everyone wants, without us having to continue to debate it ? This really *is* only an hour or two's worth of code: after which, market forces can decide which bells and whistles relating to portability and privacy the IdPs choose to implement - from the OpenID point of view, it's all "just going to work". Kind Regards, Chris Drake, =1id.com Saturday, October 14, 2006, 5:59:23 AM, you wrote: DR> CASE 2: the protocol supports only portable identifiers and no IdP-specific DR> identifiers. DR> RESULT: IdP is forced to know and store all portable identifiers for a user, DR> including identifiers for which the IdP is not authoritative, and users DR> would be forced to register all their portable identifiers with their IdP, DR> and to update these registrations every time the user adds or deletes a DR> portable identifier. Highly undesirable if not impossible. DR> * DR> Please post if you do not agree with this postulate. DR> =Drummond DR> ___ DR> specs mailing list DR> specs@openid.net DR> http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: [PROPOSAL] request nonce and name
Hi All, Just so everyone remembers: "GET" encoded "http://"; URLs usually appear en-mass in public lists (from proxy cache logs). If you don't want to "POST" data anyplace, remember to expect "replay attacks" often. Kind Regards, Chris Drake Friday, October 13, 2006, 7:48:31 PM, you wrote: JH> On 10/13/06, Martin Atkins <[EMAIL PROTECTED]> wrote: >> > 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. JH> return_to arguments can only be trusted if they are taken from the JH> signed return_to parameter, which means parsing the signed return_to JH> parameter anyway. So it's at least no worse. JH> It's better in that the parameters do not now appear twice in the JH> response (once double-encoded) JH> Example of a response with parameter in the return_to: JH> http://a.url/?drink=0xC0FFEE%21&openid.return_to=http%3A//a.url/%3Fdrink%3D0xC0FFEE%2521&;... JH> Example of a response with hypothetical openid.appdata field: JH> http://a.url/?openid.appdata=drink%3D0xC0FFEE%21&openid.return_to=http%3A//a.url/&;... JH> Josh JH> ___ JH> specs mailing list JH> specs@openid.net JH> http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: Consolidated Delegate Proposal
>> Martin wrote: >>> I'm surprised that our resident privacy advocates aren't making a >>> bigger >>> deal out of this. (If the privacy advocates have no problem then I'll >>> let this go, since this isn't a use case I feel particularly strongly >>> about myself.) >> >>Dick wrote: >> >>I was supportive of keeping the delegate from the IdP until I >>realized that the delegation was public knowledge and could not be >>hidden from the IdP. Wednesday, October 11, 2006, 4:42:35 AM, Drummond wrote: DR> The same argument convinced me, too. If public XRDS documents are what we're DR> using to provide user control of identifier synonyms and thus provide DR> identifier portability -- which is the clearest and cleanest approach we've DR> seen -- then the best thing we can do from a privacy perspective is not DR> mislead users that they are protecting their privacy by using a "public" DR> OpenID identifier and a "private" identifier with their IdP. DR> =Drummond This is backwards: Users have already chosen the IdP whom they trust to look after their identity and privacy: and except for the unlikely double-blind scenarios, no user will want to hide RP info and usage from their own IdP. The privacy violations come into effect when the *RP* is given access to any more information than it strictly needs to know to accomplish its task. Might I suggest a fast-track approach to tabling the core requirements for OpenID 2.0 and bypassing the debate: lets just identify exactly what everyone wants to achieve, make sure the proposed protocol can support everything everyone wants to do - then leave it up to the RPs and IdP's as to which features they feel like supporting. Nobody knows in advance whether privacy or delegation or any other feature is going to succeed in the marketplace, so I feel it's better to accommodate it, then let the market decide. The bottom line is that we're spending months arguing over what will end up to be a few days work and a couple of hundred lines of code. The only thing I want to see, which can then be used to accommodate privacy protection, is for RP's to accept an IdP-initiated login. It's none of the RPs business how my user selected their openid.identity for presentation to the RP. Chris. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: [PROPOSAL] bare response / bare request
KT> On Fri, 2006-10-06 at 16:34 -0700, Drummond Reed wrote: >> Let me play the dumb customer here and say: >> >> * A whole lot of real-world users would love OpenID-enabled bookmarks. >> * A whole lot of websites would love to offer them. >> * A whole lot of IdPs would love to provide them. KT> Okay Customer, if both websites and IdPs would love it, is it okay if KT> it's something that websites + IdPs can layer on top of the core? If KT> some sites chose not to, and the IdP said "login bookmark not available KT> for this site", would that be okay? Technically - the only thing we need is a mechanism for the IdP to find the RPs OpenID "bookmark entrance" - a hidden field in the original login should be sufficient: IdP can then save this URL in the users profile for them. Chris. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: [PROPOSAL] Separate Public Identifier from IdP Identifier
CHRIS DRAKE'S PROPOSED FLOW 1) User *enters* UPI, but a Discovery Agent intercepts this: UPI does *not* get posted to RP 2) Discovery Agent sends UPI to IdP 3) IdP authenticates against UPI 4) IdP selects appropriate RP-specific IPI 5) IdP initiates authentication with RP using IPI Kind Regards, Chris Drake, =1id.com ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: [PROPOSAL] Separate Public Identifier from IdP Identifier
Hi Martin, This is getting very close to what I believe is the main important thing we need in the spec to facilitate privacy, true SingleSignOn, and to help avoid confusing users by getting them to key IdP URLs. The only "tweak" I would like to see is right at the start, and is implemented using OPTIONAL (at the RP) pure client-side stuff (plain HTML or JavaScript). The server-side tweak I'd like to see would be this: An ***IdP*** can *initiate* the OpenID login with the RP using openid:Token. How the User arrived at the RP with this token is not the concern of the RP. (could be javascript, browser plugins, participating IdP helper CGIs, or even the RP itself). The point is - the guts of the authentication process remains unchanged and is backwards compatible, but all the privacy-invasive components that live at the RP are thus made *optional*. Simple as that. User only needs to remember and use one ID. User only needs to type it one time each day (or however long they elect to "stay logged on" for). Datamatching and privacy invasion are eradicated. No need to key custom IdP anonymity URLs ever. Even facilitates double-blind anonymous logins (with inclusion of a simple RP nonce extension). Win-win-win. Kind Regards, Chris Drake =1id.com Saturday, October 7, 2006, 2:49:17 AM, you wrote: MA> Dick Hardt wrote: >> I like making all identifiers work the same way. The wording around >> directed identity is somewhat confusing. Would be clearer if there >> was a complete description of what happened. ie. complete the >> transaction. In Directed Identity, the RP needs to do discovery on >> the identifier provided to make sure the IdP is authoritative for it. >> MA> Perhaps I've misunderstood how directed identity works, but I figured MA> the flow would work as follows: MA> * The RP initiates Yadis discovery on http://anon.myidp.com/ MA> * The IdP returns a document naming its authentication endpoint (in the MA> "URI" field) and a special anonymous token as openid:Token. openid:Token MA> may be the same as the public identifier from the previous step, but MA> this is not required. MA> * The RP initiates OpenID auth to the named endpoint using the openid:Token. MA> * The IdP notes that the special "anonymous" token has been used, but it MA> knows who the remote user is (via Cookies, for example) so it can MA> generate an identifier and remember that it belongs to that user/RP combo. MA> * IdP responds to RP with the generated public identifier (which *is* MA> publically resolvable, of course.) MA> * RP resolves the IdP-provided public identifier, where the IdP will MA> provide for Yadis discovery and specify that it is authoritative for MA> that URL. MA> * We're done. MA> The important thing is that, just as I've separated the public MA> identifier from the IdP token (or handle, if you like), this separation MA> also applies to the IdP-generated public identifier. MA> (sorry that this is a bit rough. I've not really spent the necessary MA> amount of time preparing the above and I'm in a hurry, so if there are MA> spots where I'm not clear I apologise and I'll clarify later! :) ) MA> ___ MA> specs mailing list MA> specs@openid.net MA> http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Adoption questions
I still worry about end-user experience, privacy, and OpenID usefulness to RPs running non-trivial services. Can someone outline how user privacy gets maintained? (and what, if anything, a user needs to do and/or understand to support this?) Would any RP handling, say, credit-card data, be comfortable with adopting the proposed spec? Think: Amazon, wanting to re-authenticate upon purchase. Is my understanding accurate: OpenID is unable to support single sign on. If not - lets assume it's 9am. I just signed on. I can visit RP#1 then RP#2 then RP#3 and go back and forth all day without hindrance, until I next sign off - yes? Privacy: during any hypothetical overheard lunchtime conversation between The CEO of RP#1 and the CEO of RP#2 - nobody's ever going to hear this fragment of conversation: "... yeah - that troublemaker is one of our users too ..." - or are they? Sorry to harp on about the fundamentals. I'm not so sure the under-hood work is as important as the "big picture", and I don't think we've got this last bit right yet. Kind Regards, Chris Drake, =1id.com ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: Strong Authencation (was [PROPOSAL] authentication age
Hi Drummond, Example1: RSA would provide a signed response indicating that the user correctly entered the SecurID token code. Example2: The RP would have the public key of the company that supplies the fingerprint scanning hardware (although some extra thought as to how a fingerprint ultimately matches to an Identity is required, which will need an entirely different information flow to Example1). Is Dick a vendor himself? he no doubt knows other ways. Kind Regards, Chris Drake, =1id.com Friday, October 6, 2006, 3:19:44 AM, you wrote: DR> Dick, DR> You say, " The strong authentication will be supplied by a vendor that has DR> been certified to provide standardized levels of authentication. The IdP DR> will often NOT be the strong auth vendor." DR> Can you explain how this might work, i.e., how can the RP have a DR> relationship directly with the strong auth vendor and not the IdP? Would the DR> IdP be outsourcing authentication to the strong auth vendor? In which case, DR> isn't the strong auth vendor the IdP? DR> =Drummond DR> -Original Message- DR> From: [EMAIL PROTECTED] DR> [mailto:[EMAIL PROTECTED] On Behalf DR> Of Dick Hardt DR> Sent: Thursday, October 05, 2006 9:36 AM DR> To: Gabe Wachob DR> Cc: specs@openid.net DR> Subject: Strong Authencation (was [PROPOSAL] authentication age DR> The vision I have is that strong authentication to your IdP will be DR> common in the future. DR> The strong authentication will be supplied by a vendor that has been DR> certified to provide standardized levels of authentication. The IdP DR> will often NOT be the strong auth vendor. DR> The RP will have a trust relationship with the vendor, likely through DR> a vendor consortium that delegates to vendors that their product is DR> certified, ie. the RP will not need to trust each vendor, just the DR> certification body. DR> I would hope that OpenID can be extended over time to be able to move DR> around these types of strong auth assertions. DR> -- Dick DR> On 4-Oct-06, at 8:41 PM, Gabe Wachob wrote: >> Chris- >> As someone who has recently come from working in the financial >> sector (Visa), its clear that OpenID is NOT intended for >> authentication >> where the *relying party* cares about how the authentication is >> performed. >> >> At places like Visa and for home banking, this means that OpenID, >> without something more, is clearly a non-starter. These relying >> parties want >> to know exactly how their users are being authenticated because their >> business is all about risk management and creating business >> opportunities >> around very good knowledge of the risk profile of each transaction >> type. >> >> That all being said, I believe it should be possible to layer on >> OpenID a form of IDP control such that a relying party can require >> a certain >> class or group of IDPs be used when presenting authentication >> assertions to >> them. The actual *policy* for how these IDPs are approved is probably >> orthogonal to the protocol spec, but "secure" identification of >> those IDPs >> (relative to some trust root, etc) could probably be made into an >> extension >> usable for those parties who want it. >> >> My guess is that culturally, most people involved in OpenID have >> *not* been interested in addressing these concerns. However, >> expectations >> need to be better managed around these sort of "relying-party cares" >> scenarios, because its not obvious without actually reading the specs >> themselves... >> >> -Gabe >> >>> -Original Message- >>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >>> On Behalf >>> Of Chris Drake >>> Sent: Wednesday, October 04, 2006 8:26 PM >>> To: Kevin Turner >>> Cc: specs@openid.net >>> Subject: Re[2]: [PROPOSAL] authentication age >>> >>> Hi Kevin, >>> >>> Sounds like you're leaning towards a root authority for IdPs who can >>> audit procedures and verify protection in order to sign the IdP's >>> keys? >>> >>> Joe blogger doesn't care much about identity assertions from an IdP, >>> but it's a reasonable bet to expect that a Bank might care... >>> >>> Kind Regards, >>> Chris Drake >>> >>> >>> ___ >>> specs mailing list >>> specs@openid.net >>> http://openid.net/mailman/listinfo/specs >> >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs >> >> DR> ___ DR> specs mailing list DR> specs@openid.net DR> http://openid.net/mailman/listinfo/specs DR> ___ DR> specs mailing list DR> specs@openid.net DR> http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Strong Authencation (was [PROPOSAL] authentication age
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. Kind Regards, Chris Drake ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[4]: [PROPOSAL] authentication age
Hi Gabe, Beautifully worded, and (IMHO) an extremely valuable real-world opinion. I too believe OpenID is currently a "non-starter". I have dual vested interests: I want OpenID to succeed, *especially* for RPs like Visa, since my IdP makes money from supporting OpenID only when OpenID ends up getting used. I also believe that an IdP (and mine in particular) is well suited for deploying secure technology (eg: two factor tokens). If, aside from making OpenID actually *work* for the likes of Visa, we can build in the ability to provide a tangible *benefit* to Visa from using it (that is: allow visa to REQUIRE that a user has authenticate via two-factor means, to an accredited - i.e: explicitly trusted by Visa - IdP) then we've not only cemented the future of OpenID, we've gone an improved a pile of security problems along the way. Kind Regards, Chris Drake 1id.com Thursday, October 5, 2006, 1:41:34 PM, you wrote: GW> Chris- GW> As someone who has recently come from working in the financial GW> sector (Visa), its clear that OpenID is NOT intended for authentication GW> where the *relying party* cares about how the authentication is performed. GW> At places like Visa and for home banking, this means that OpenID, GW> without something more, is clearly a . These relying parties want GW> to know exactly how their users are being authenticated because their GW> business is all about risk management and creating business opportunities GW> around very good knowledge of the risk profile of each transaction type. GW> That all being said, I believe it should be possible to layer on GW> OpenID a form of IDP control such that a relying party can require a certain GW> class or group of IDPs be used when presenting authentication assertions to GW> them. The actual *policy* for how these IDPs are approved is probably GW> orthogonal to the protocol spec, but "secure" identification of those IDPs GW> (relative to some trust root, etc) could probably be made into an extension GW> usable for those parties who want it. GW> My guess is that culturally, most people involved in OpenID have GW> *not* been interested in addressing these concerns. However, expectations GW> need to be better managed around these sort of "relying-party cares" GW> scenarios, because its not obvious without actually reading the specs GW> themselves... GW> -Gabe >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf >> Of Chris Drake >> Sent: Wednesday, October 04, 2006 8:26 PM >> To: Kevin Turner >> Cc: specs@openid.net >> Subject: Re[2]: [PROPOSAL] authentication age >> >> Hi Kevin, >> >> Sounds like you're leaning towards a root authority for IdPs who can >> audit procedures and verify protection in order to sign the IdP's >> keys? >> >> Joe blogger doesn't care much about identity assertions from an IdP, >> but it's a reasonable bet to expect that a Bank might care... >> >> Kind Regards, >> Chris Drake >> >> >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: [PROPOSAL] authentication age
Hi Kevin, Sounds like you're leaning towards a root authority for IdPs who can audit procedures and verify protection in order to sign the IdP's keys? Joe blogger doesn't care much about identity assertions from an IdP, but it's a reasonable bet to expect that a Bank might care... Kind Regards, Chris Drake ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: IdP-supported delegation
Hi All, I've been absent 2 months, and missed the announcement of this list. On a brief skim of the archive re delegation, I can't see a clearcut agreement yet? There was also talk of omitting delegation from the first draft - did this omission go ahead? I would like to propose the following. 1. RP (Relying Party) *requests* a users identifier (eg: global iname) in RPs login on their web site, however, the post target for this form is *not* the RP, but instead the RP's IdP (iBroker). 2. Users may... A) Key in their unique global identifier B) Key in their actual IdP URL C) Enter nothing at all and click either the "login" button, or the inames logo D) Not click anything at all (as would be the case if their browser held an RP-issued cookie stating "stay logged on") 3. The RPs iBroker agrees to suitably issue HTTP redirects to the correct iBroker should they discover they're not the correct IdP for the user. Solves: i) eradicates the difficult-for-end-users-to-understand problem of trying to explain to them why they formerly needed to enter other stuff besides their iname to log in - from a users perspective, they only need log in one time, using their genuine favorite identifier. ii) Privacy problems solved: control over which identifier to subsequently present to RP is returned to the user. At NO time does the users keyed identifier need or get communicated to the RP Facilitates: iii) Genuine single-signon (SSO) - Just because a user only has to type their *password* once, doesn't make that a "single sign on" in my opinion. If I have SIGNED ON - I do not expect to have to re-type my wretched identifier every time I visit a new RP. I just want to click *once*, or, not even click at all. iv) A single sign off (SSOFF?) - the "log out" problem: many RPs support "stay logged on" features, so to expect an RP to use OpenID, we should also support this, or risk them all having to implement this themselves, which robs our users of the ability to "log out" from every place they are currently logged in to. v) Anonymous single signon, but still using just our users favorite identifier vi) Automatic IdP-provided unique identifier provision - RP site always gets the same identifier for the user, which is never the same as the identifier the user keyed in, and such identifier is never shared amongst RPs vii) Double-blind anonymous single sign on (neither does the RP know the users identifier nor iBroker, nor does the iBroker know what RP the user is signing in to.) [requires a nonce, which we already have for other reasons anyway] viii) Lets a user log in to any site they've joined, simply by clicking on it in the list on their own personal iBroker sites page at their IdP. Requires: ix) iBrokers to co-operate, and possibly someone to administer a root key to sign certificates to allow RPs to automatically ascertain the accreditation and policy status of the iBroker In general, my coding and standards philosophy is to cater for as much as possible, even if it's not all initially implemented. Also in general, my UI philosophy is to make everything as utterly simple for users as we possibly can. I think my the above proposal caters for both. As an IdP myself (1id.com) I offer to implement the above. I also offer my response to Josh Hoyts worry:- >On Sep 4, 2006, at 13:00, Josh Hoyt wrote: >> I think that disclosing the identifier to the *IdP* is a non-issue. >> The only potential issue is that some IdP may choose not to support >> delegation in order to lock in users. My IdP will properly honor delegation issues, and will not store or use the flow of other IdP's identifiers for anything. (indeed, if delegation is global, then all RPs for whom I am their iBroker will therefore gain the advantage that even if other IdPs don't commit to the same practice as me - all their users still get the advantages of a working and functional solution, by virtue of my place in the middle - e.g. my step numbered "3." above) Kind Regards, Chris Drake ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
