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 link 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 LINK 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/mailman/listinfo/user-experience
Kind Regards,
Chris Drake,
=1id.com
Thursday, April 3, 2008, 4:38:13 AM, you wrote:
Dick Hardt wrote:
:-) ... that label would be more accurate. There is lots of work to be
done to make OpenID simpler for users. I think that what will be easy
for users is something provided by the browser that lets the user
click to initiate a login or registration. No typing is better then
any typing! Back when we started working on the protocols we could not
expect this kind of functionality to be in the browsers. Now that
awareness is higher, having it built
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[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 link 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 usefulness of Identity management. Kind Regards, Chris Drake Thursday, April 5, 2007, 5:14:58 PM, you wrote: MA Not sure if you deliberately took this off-list, but I'll reply directly MA and let you divert it back to list if you want. :) MA Chris Drake wrote: MA For some things it's
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
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
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
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]: [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):- link rel=openid.httpauth href=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]: 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[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. lid.gif 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[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 FORM page, like a META or LINK 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. lid.gif 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: 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[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[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%21openid.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%21openid.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] 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
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] 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 FORM 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
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[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
