Re: Server-to-server channel
[I initially sent this to Chris directly, because he sent his message to me directly. Then I noticed he'd also replied on the list. Hopefully he'll see this before my private reply and we can avoid another go-around of duplicate messages!] Chris Drake wrote: MA For some things it's legitimate: they need to store your name because MA otherwise they'd need to talk to your OP (via you!) every time they MA render a page containing something attributed to you. OK - yes - I concede that some data age complexity does probably creep back in if RPs choose to deny users the opportunity to audit the use of user information. (If I've got a choice between 2 RPs, and RP1 renders pages with my name in it, without giving me control over that, while RP2 makes repeated calls to my OP every time it occurs: I'll always choose to use RP2 - because it's the only one of the 2 options that's user centric, and gives me the ability to control the use of my information. Yes - this could be a tough drain on RP and OP resources. Tough. You can't just wash your hands of this problem because it doesn't suit your rather bizarre idea about how the world should be. Sites need to be able to attribute contributions to users, and in order to do that they need the user's name. A forum site cannot retrieve the name of every user that took part in a topic from their respective OPs while rendering the topic page. Tough is not an acceptable answer: rendering a topic page is a legitimate function of a forum site and attributing each message is necessary. MA they need to store your name because MA otherwise they'd need to talk to your OP (via you!) via you! is not a correct statement. This is a server-to-server topic: we're discussing a data flow that is by your explicit prior permission, but that takes place when you are not necessarily present. Right. Some people had been talking about not allowing this out-of-band information fetching. Even without the need for the user to be present, it's still prohibitively expensive. MA For other things it's more dubious than that, but the fact that it MA is technically possible means that at least some RP's will do it. MA I think it'd be a mistake to write the spec under the assumption MA that they won't unless we're going to include something that MA prevents it. I do not follow your logic. It looks like you're saying there is an opportunity for some RP's to act badly, therefore we should not even try to code user-protection into the protocol On the contrary, I'm saying that if you don't want RPs to retain user information then you should include some TECHNICAL MEASURE that prevents them from doing so. I think an acceptable compromise is to instead give users a way to express their wishes about how the data can be retained in the form of a update this every n months/weeks/years/whatever or a hard expires on this date-type rule. This way you acknowledge that there are indeed applications that need to retain user information for certain purposes and allow the user to have some control over this process. You could also put in a don't retain this at all flag, which in my forum case would probably cause the forum to just identify you by your raw OpenID identifier and have done with it. By all means - include preventative code (and for some kinds of attributes, digital time-stamped and signed assersions about the attributes solve these problems). But I think it's a far bigger mistake to completely leave out a server-to-server channel altogether. I have nothing against the server-to-server channel. In fact, the server-to-server channel is a prerequisite for the update this every n months thing because otherwise the RP would have no way to do that update. When a rogue RP violates your trust and caches data without your permission, that's bad. So a way is is needed for: * A trustworthy RP to indicate how long it would like to retain certain items of data * A user to indicate how long he would like certain items of data retained for, or how often the RP should try to refresh that data. * A way for the user to prevent further updates of a particular attribute by a particular RP after a certain date. The first and second points above would, I think, be helped by defining some reasonable defaults for each attribute type, just so that the average user doesn't necessarily have to spend ages entering update frequencies and expiry dates every time some attributes are requested for the first time. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[3]: Server-to-server channel
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 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 MA able to attribute contributions to users, and in order to do that they MA need the user's name. A forum site cannot retrieve the name of every MA user that took part in a topic from their respective OPs while rendering MA the topic page. Tough is not an acceptable answer: rendering a topic MA page is a legitimate function of a forum site and attributing each MA message is necessary. MA they need to store your name because MA otherwise they'd need to talk to your OP (via you!) via you! is not a correct statement. This is a server-to-server topic: we're discussing a data flow that is by your explicit prior permission, but that takes place when you are not necessarily present. MA Right. Some people had been talking about not allowing this out-of-band MA information fetching. Even without the need for the user to be present, MA it's still prohibitively expensive. MA For other things it's more dubious than that, but the fact that it MA is technically possible means that at least some RP's will do it. MA I think it'd be a mistake to write the spec under the assumption MA that they won't unless we're going to include something that MA prevents it. I do not follow your logic. It looks like you're saying there is an opportunity for some RP's to act badly, therefore we should not even try to code user-protection into the protocol MA On the contrary, I'm saying that if you don't want RPs to retain user MA information then you should include some TECHNICAL MEASURE that prevents MA them from doing so. MA I think an acceptable compromise is to instead give users a way to MA express their wishes about how the data can be retained in the form of a MA update this every n months/weeks/years/whatever or a hard expires on MA this date-type rule. This way you acknowledge that there are indeed MA applications that need to retain user information for certain purposes MA and allow the user to have some control over this process. You could MA also put in a don't retain this at all flag, which in my forum case MA would probably cause the forum to just identify you by your raw OpenID MA identifier and have done with it. By all means - include preventative code (and for some kinds of attributes, digital time-stamped and signed assersions about the attributes solve these problems). But I think it's a far bigger mistake to completely leave out a server-to-server channel altogether. MA I have nothing against the server-to-server channel. In fact, the MA server-to-server channel is a prerequisite for the update this every n MA months thing because otherwise the RP would have no way to do that update. When a rogue RP violates your trust and caches data without your permission, that's bad. MA So a way is is needed for: MA * A trustworthy RP to indicate how long it would like to retain MA certain items of data MA * A user to indicate how long he would like certain items of data MA retained for, or how often the RP should try to refresh that data. MA * A way for the user to prevent further updates of a particular MA attribute by a particular RP after a certain date. MA The first and second points above would, I think, be helped by defining MA some reasonable defaults for each attribute type, just so that the MA average user doesn't necessarily have to spend ages entering update MA frequencies and expiry dates every time some attributes are requested MA for the first time. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
On Wed, 2007-04-04 at 20:02 +, Vinay Gupta wrote: On Apr 4, 2007, at 7:43 PM, Douglas Otis wrote: Hm. Well, I don't to suggest that we tear off fixing or expressing the whole semantics of PKI, but I do think that some care should be taken to make sure that it's clear what the security status of a returned key is. Problems like Confused Deputy can easily arise when you start dealing with registry systems which aren't under really tight control. I don't have a neatly packaged solution for this, but we're dealing with situations which can have very significant legal repercussions: digital signatures are legal for some kinds of transactions in some jurisdictions, and however this is handled is has to have some approach to the questions of what is they key good for, and who says OpenID appears fairly prone to phishing exploits, as it expects a user to pay close attention to where they end up and the other URL involved. OpenID could evolve into offering public keys during the initial logins along with other identity attributes that could help solve this problem. The RP could retain keys for some period since last use to suppress the number of times OpenID is invoked. Rather than an expiry, the attribute might want to be defined differently. Some key agent would be needed that replicates the authentication process now available using SSH. This does not depend upon certificates, but rather a simple list of public keys. Once this concept becomes routine, other applications will likely include this mode of operation where identifying the application becomes important. This would _not_ be a certificate as you seem to imply. Try to keep it simple, but if an attribute can include a Time to Live or Expiry parameter, then it would be nice to have a class of attributes identified as public keys with sub-attributes for the application, where the default would be some OpenID compliant HTTP access scheme. An application that would not require development, other than maintaining a list of keys, would be SSH. Although perhaps too complex for the average user, SSH could also be used to authenticate web access. This is standard for any Unix based OS, and could be found by using Putty and Pageant on a Windows platform. There is even an interesting version of this that runs from a USB flash: http://www.chiark.greenend.org.uk/%7Esgtatham/putty/ Although the world demands GUI, terminal interfaces already offer a powerful set of tools for doing exactly what is needed. Public key cryptography reduces the overhead and security concerns substantially. This may also provide an alternative for rather complex OpenID extensions that will likely over reach with respect to security. -Doug ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel (now: Kerberos, Phishing)
One further thought on Kerberos: as far as I know, Kerberos is a minimal implementation - nothing simpler than this actually works in the real world, and the Kerberos operating environment is a bit simpler than what is being discussed in some instances here, in terms of managing the language of what access permissions are being granted by this sign-on event. One thing I'd like to suggest we examine is personal customization as a way to prevent Phishing. For example, say that my OpenID service provider serves pages to me over HTTPS, and furthermore allows me to upload my own color preference and background images. Now, nobody who isn't logged in as me can see my image and colors, so if somebody tries to mount Man In The Middle, they can't get access to my images etc. and the page will look all wrong. Sounds dumb but it might actually work pretty well in practice... But the key is that those images have to be private, so that they foe can't spider the page and show you a copy. Vinay -- Vinay Gupta - Designer, Hexayurt Project - an excellent public domain refugee shelter system Gizmo Project VOIP: 775-743-1851 (usually works!) Cell: Iceland (+354) 869-4605 http://howtolivewiki.com/hexayurt - old http://appropedia.org/ Hexayurt_Project - new Skype/Gizmo/Gtalk: hexayurt I have a proof which unfortunately this signature is too short ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Re[2]: Server-to-server channel
On 4-Apr-07, at 8:59 PM, Chris Drake wrote: 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. Having your public key discoverable at your URL makes lots of sense, it is by its very nature, public. I would not consider fetching the public key to be a transaction though. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Server-to-server channel
I would think this would be better solved by leveraging the Oracle Identity Framework and using components such as AAPML and CARML Message: 3 Date: Thu, 5 Apr 2007 10:57:22 + From: Vinay Gupta [EMAIL PROTECTED] Subject: Re: Re[3]: Server-to-server channel To: Chris Drake [EMAIL PROTECTED] Cc: Martin Atkins [EMAIL PROTECTED], specs@openid.net Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On having your private data cached: the current web model allows businesses to simply own your data into a database, correlate it across multiple databases (doubleclick) and so on. I think that to expect them to give up this privilege (and revenue stream from targeted advertising) is unrealistic, and caching OpenID data is necessary for them to do so. Therefore, I'd suggest that OpenID examines the various schemes for providing a Terms of Service **from the user end** on access to personal data: by accessing my address, you attest that you will not 1 store it for more than 30 days after our business transaction is complete, 2 share it with anybody else and so on. I seem to remember that somebody had a language for expressing those kinds of privacy preferences in a machine readable form but I'm not having any luck remembering who it was... Possibly the XRI folks know? At least at that point, users can use the penalty clause on that shrinkwrap license on their personal data to sue scumbags (and if you break these rules, you pay me $500.) HIPPA may also help. Vinay * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
Chris Drake wrote: Hi Martin, Yes - sorry - I accidentally hit reply instead of reply all. I later did re-post to the list though. For the benefit of the list, your reply is at the end here. Re-reading my reply, I think my wording sounded pretty strong, and I might not have made it clear that I'm not pushing for 100% of data to live at the OP: rather - I want to give the user a choice in the matter (that is - after all - the entire spirit of user-centric). I want users to have the *option* to decide whether to sign up to RP#A or RP#B, and be able to base their decision upon the data-handling and protection practices of the RP. Some RP's will want to store everything just like they do today. Some will want to embrace user centricity and give their customers full control, and most will probably tread a line somewhere inbetween. As long as we build something that supports all this, then we can leave it up to the normal market forces to steer the Identity future the way they want - with the key issue (for us) being that OpenID has the chance to persist in this future. Right now - OpenID is right at the bottom of the pile, being almost the worst Identity 2.0 protocol currently on the market. IMHO - this is a problem that's easily fixed. I believe we are aiming for much the same thing, though perhaps I'm coming at it from a different perspective. My original message was proposing support for expressing the user's desires for how long particular data items should be retained without refreshing them, which seems to fit into your world view as described above. I was simply suggesting that expecting RPs to retain *no information at all* is unrealistic, and so we should provide a mechanism for users to express how they would like their data to be used rather than just assuming that RPs will retain nothing. I wrote: Yes - this could be a tough drain on RP and OP resources. Tough. You wrote: MA You can't just wash your hands of this problem because it doesn't suit MA your rather bizarre idea about how the world should be. Sites need to be I contest that I *am* allowed to wash my hands at this point, because it is absolutely my problem: I operate an OP, and I'm involved in helping RPs accomplish Web 2.0 goals. I'm smack in the middle of all the consequences that flow from allowing users to control their own data howsoever they wish. I further contest that the idea of me being in control of my own information about me is not bizarre. It might not be how anything on the web works today - true - but I'm pretty confident this is something most people do, or will, want. Imagine you're at the newsagent buying a magazine. You hand over your credit card, and the shopkeeper says No problem - I'm happy to sell you your goods, but I need you to first agree to let me make a photocopy of your credit card, grab you name and email address, and keep it in all on our files for the next 10 years. Oh - and we'll need to be sending you the occasional marketing message from time to time over those 10 years as well. Now *that* is something that almost everyone will agree is bizarre. Note that I was focusing on the example you gave of a user's name, rather than of a user's credit card information. Different data deserves different treatment. I'll wholeheartedly agree that it's undesirable for a vendor to retain credit card information — they currently do so largely because there's nowhere else that it can be centrally stored and retrieved, but AX changes that — but other data such as a user's name are another matter. When I meet people, I routinely tell them my name. I don't expect them to immediately forget my name after our conversation — in fact, like most people, I'm probably subconsciously offended when people *don't* remember my name. I control people's access to that data by simply not telling them in the first place. I think that what we can take from this misunderstanding is that not only do different *attributes* have different usage expectations, but also different *situations* have different usage expectations: you're largely focusing on businesses and financial transactions, while I'm largely focusing on social situations such as forums, weblogs and social networking. This may be caused by a difference in our backgrounds or interests, but whatever the reason it does show that different situations call for different behavior, and is yet another reason why users should be able to express their desires on a case-by-case basis if it is important for them to do so. I like Vinay's subsequent suggestion that this somehow be made legally binding, although I'm not sufficiently knowledgable about the relevant law to know how that can be put into practice. [snip] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[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: Server-to-server channel
Chris Drake wrote: Hi Martin, You wrote MA The age of the information needs to be taken into account here. When the information (rightly) lives at the OP instead of the RP, none of that age complexity exists. It's *my* name. It's *my* credit card. If any RP wants this info, make them come to me (my OP) and get it. Let me say no. Let me know each time they ask. But most importantly, let me (my OP) provide the correct, updated info each time the RP wants it. I think you're kidding yourself if you believe that RP's won't cache the information they obtain. For some things it's legitimate: they need to store your name because otherwise they'd need to talk to your OP (via you!) every time they render a page containing something attributed to you. For other things it's more dubious than that, but the fact that it is technically possible means that at least some RP's will do it. I think it'd be a mistake to write the spec under the assumption that they won't unless we're going to include something that prevents it. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
On Apr 4, 2007, at 12:45 AM, Martin Atkins wrote: 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 ... The age of the information needs to be taken into account here. If information is old, then the RP would presumably be hesitant to act on it without verification. What constitutes old information depends on the attribute... things like Full Name are, for many people, changed never or at most once in their lives. However, things like a credit card number tend to change every few years as cards expire. Some information has a built-in expiry date (such as credit card details), while other information just has a likelyhood of change. This implies to me that the following three things are needed: * The possibility of a hard expiry date on a particular piece of information. * soft expiry dates which are more like refresh this every n months, where the RP gets less and less convinced about the accuracy of the data as it ages, but may continue to use it for some time even when it's a bit old. * The ability for an RP to request a refresh of attributes it stores without necessarily including the user in the transaction. (The user presumably will have made approval/revoking decisions out of band at an earlier time.) This may seem to be off topic, but I really don't see reluctance in using public key cryptography. DKIM would be one such example. Nearly every gateway, and access point can utilize this means of authentication. Think of this as yet another means to control an account without relying upon OpenID. OpenID opens the door, where you then hand them your public key. One might also wish to specifically define attributes containing public keys used by the identity. This would be information uploaded by the individual after creating their id_rsa.pub key information using either system tools or specialized applications. This would provide an alternative access method that would not rely upon OpenID exchanges. Here again, an expiry might prove handy, and so would a means to revoke the key. Perhaps this would be done by overlaying it. There could be keys used to authorize some other automated service, or to act as a replacement for OpenID once the key has been established. One might be defined for email, IM, VoIP, etc. -Doug ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
On Apr 4, 2007, at 6:13 PM, Douglas Otis wrote: This may seem to be off topic, but I really don't see reluctance in using public key cryptography. DKIM would be one such example. Nearly every gateway, and access point can utilize this means of authentication. Think of this as yet another means to control an account without relying upon OpenID. OpenID opens the door, where you then hand them your public key. One might also wish to specifically define attributes containing public keys used by the identity. This would be information uploaded by the individual after creating their id_rsa.pub key information using either system tools or specialized applications. This would provide an alternative access method that would not rely upon OpenID exchanges. Here again, an expiry might prove handy, and so would a means to revoke the key. Perhaps this would be done by overlaying it. There could be keys used to authorize some other automated service, or to act as a replacement for OpenID once the key has been established. One might be defined for email, IM, VoIP, etc. It's not the public key management in a scheme like this that concerns me... Two issues: private key management - are the keys scattered, like your VOIP key lives in Gizmo, and your SSH key lives in your .ssh, and so on? Or do we by logical extension begin to impose some order here and have one key pair per person... you see where this goes, right? Secondly X509 certificates are very, very broken in terms of delegation semantics and certification semantics (at least in many people's eyes, mine included.) So.. SPKI? (yes, I've been over this territory and that's pretty much what I'm doing here.) Vinay -- Vinay Gupta - Designer, Hexayurt Project - an excellent public domain refugee shelter system Gizmo Project VOIP: 775-743-1851 (usually works!) Cell: Iceland (+354) 869-4605 http://howtolivewiki.com/hexayurt - old http://appropedia.org/ Hexayurt_Project - new Skype/Gizmo/Gtalk: hexayurt I have a proof which unfortunately this signature is too short ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
On Apr 4, 2007, at 11:44 AM, Vinay Gupta wrote: On Apr 4, 2007, at 6:13 PM, Douglas Otis wrote: There could be keys used to authorize some other automated service, or to act as a replacement for OpenID once the key has been established. One might be defined for email, IM, VoIP, etc. It's not the public key management in a scheme like this that concerns me... Two issues: private key management - are the keys scattered, like your VOIP key lives in Gizmo, and your SSH key lives in your .ssh, and so on? Or do we by logical extension begin to impose some order here and have one key pair per person... you see where this goes, right? Related services that can be enabled by using OpenID as a key distribution scheme. Keys would need to relate to services handled by the consumer or RP. A sub-attribute could help facilitate correct placement of the keys and to allow different keys for different purposes. Secondly X509 certificates are very, very broken in terms of delegation semantics and certification semantics (at least in many people's eyes, mine included.) So.. SPKI? (yes, I've been over this territory and that's pretty much what I'm doing here.) How these keys are handled internally could be left to the consumer or RP. Either the OpenID server or the Consumer or RP could fashion their own certs based upon this information where it is administered and integrated with other services. The individual end-user would only need to submit their set of public keys for this to become possible. -Doug ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
On Apr 4, 2007, at 7:43 PM, Douglas Otis wrote: Related services that can be enabled by using OpenID as a key distribution scheme. Keys would need to relate to services handled by the consumer or RP. A sub-attribute could help facilitate correct placement of the keys and to allow different keys for different purposes. Secondly X509 certificates are very, very broken in terms of delegation semantics and certification semantics (at least in many people's eyes, mine included.) So.. SPKI? (yes, I've been over this territory and that's pretty much what I'm doing here.) How these keys are handled internally could be left to the consumer or RP. Either the OpenID server or the Consumer or RP could fashion their own certs based upon this information where it is administered and integrated with other services. The individual end-user would only need to submit their set of public keys for this to become possible. Hm. Well, I don't to suggest that we tear off fixing or expressing the whole semantics of PKI, but I do think that some care should be taken to make sure that it's clear what the security status of a returned key is. Problems like Confused Deputy can easily arise when you start dealing with registry systems which aren't under really tight control. I don't have a neatly packaged solution for this, but we're dealing with situations which can have very significant legal repercussions: digital signatures are legal for some kinds of transactions in some jurisdictions, and however this is handled is has to have some approach to the questions of what is they key good for, and who says it's OK for this purpose? Vinay -- Vinay Gupta - Designer, Hexayurt Project - an excellent public domain refugee shelter system Gizmo Project VOIP: 775-743-1851 (usually works!) Cell: Iceland (+354) 869-4605 http://howtolivewiki.com/hexayurt - old http://appropedia.org/ Hexayurt_Project - new Skype/Gizmo/Gtalk: hexayurt I have a proof which unfortunately this signature is too short ___ 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: Re[2]: Server-to-server channel
This was, of course, the original LID design, and you are presenting the rationale for it. See http://lid.netmesh.org/ On Apr 4, 2007, at 20:59, Chris Drake wrote: 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 ___ 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: Server-to-server channel
Johnny Bufu wrote: This is basically a push approach, as opposed to the pull approach you were suggesting. I'm new to OpenID, and no engineer, but I have to say that I have a bad feeling about this 'push' approach. It inverts the relationship between client and server and seems entirely contrary to the stateless spirit of the Web: * The RP can't know the status of the information it is working with - it just have to assume that the attributes it has in store are up-to-date. * If an OP fails to update an attribute, the RP will never know - no fall-backs can be implemented. * When updating, the OP impose a previous address structure upon the Web, regardless of how it is actually organized now. * While the RP's requests the information, the OP is made responsible for doing the work associated with distributing it. * The OP must donate storage space to support the distribution of information to RP's it has no direct interest in. A malicious RP may even exploit this storage space for own purposes. * Attributes are not easily referenced to, say, sub-contractors of an RP. The model impose limits upon the complexity of the services that may be derived from it. Regards, Anders Feder ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
Good questions to tease out the logic behind the architecture Anders, responses to each of your points below ... On 3-Apr-07, at 6:18 AM, Anders Feder wrote: Johnny Bufu wrote: This is basically a push approach, as opposed to the pull approach you were suggesting. I'm new to OpenID, and no engineer, but I have to say that I have a bad feeling about this 'push' approach. It inverts the relationship between client and server and seems entirely contrary to the stateless spirit of the Web: There are two common client server design patterns. Request / Response and Publish / Subscribe. * The RP can't know the status of the information it is working with - it just have to assume that the attributes it has in store are up- to-date. The RP has what ever the user last gave the RP. If the user is involved in the transaction, the RP may ask the user for up to date information. Note that your concern is constrained to situations where the user is not involved. * If an OP fails to update an attribute, the RP will never know - no fall-backs can be implemented. When the data changes, the user then decides if the RP gets the data. If the user did not want the RP to get, well that is what the user decided. This is user centric after all. * When updating, the OP impose a previous address structure upon the Web, regardless of how it is actually organized now. The converse would be the RP imposes an address structure on the OP on where to get the updated data. * While the RP's requests the information, the OP is made responsible for doing the work associated with distributing it. Well, the OP would be responsible for responding to all the myriad useless RP requests for updated data if a pull model. Now the OP and RP only need to move data if the data has changed and the user wants to push the update to the RP. * The OP must donate storage space to support the distribution of information to RP's it has no direct interest in. A malicious RP may even exploit this storage space for own purposes. The alternative would be the OP would need to donate storage to support which RPs are allowed to ask for data. * Attributes are not easily referenced to, say, sub-contractors of an RP. The model impose limits upon the complexity of the services that may be derived from it. The same flow could happen between the RP and dependent services. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
On 3-Apr-07, at 8:24 AM, Dick Hardt wrote: On 2-Apr-07, at 11:50 AM, Chris Drake wrote: 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. I understand why you think User Centric implies a site does not store anything about me. oops I *don't* understand why you think ... User Centric implies that the user is the center of the transaction. Server to server is so NOT User Centric! -- 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
Re: Server-to-server channel
On 3-Apr-07, at 9:18 AM, Anders Feder wrote: * The RP can't know the status of the information it is working with - it just have to assume that the attributes it has in store are up- to-date. The RP can send an update_url to the OP when it fetches the attributes, so it will get new values when the user changes them at the OP. * If an OP fails to update an attribute, the RP will never know - no fall-backs can be implemented. Fails when? On a Store request? * The OP must donate storage space to support the distribution of information to RP's it has no direct interest in. A malicious RP may even exploit this storage space for own purposes. Not sure I understand this. OP's normally would not have interest in any particular RPs the User has interest in RPs :) Although it is up to the individual OP to set rules about who it wants to talk to. * Attributes are not easily referenced to, say, sub-contractors of an RP. The model impose limits upon the complexity of the services that may be derived from it. You're free to publish the RDF for the attributes you support... then they are reference-able aren't they? -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
Rowan, Thanks for your response. Again, I have no formal education, so don't bother if my comments are worthless. I just want to specify the concerns I do have, based on my own experience, in case they are of any use to the process. Rowan Kerr skrev: The RP can send an update_url to the OP when it fetches the attributes, so it will get new values when the user changes them at the OP. But the RP can't know if the update_url is honored, i.e. if it will ever receive any updates from the OP. 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 ... One could say that OpenID should not be relied on to exchange sensitive information like bank account numbers, but 1) I think its a shame to limit a technology with such great potential, and 2) chances are that OpenID will be relied upon anyway - the sensitive transactions will just be performed longer down the chain, where they can't be checked. * If an OP fails to update an attribute, the RP will never know - no fall-backs can be implemented. Fails when? On a Store request? Yes, or if the Store request never leaves the OP server, for whatever reason. Not sure I understand this. OP's normally would not have interest in any particular RPs the User has interest in RPs :) Although it is up to the individual OP to set rules about who it wants to talk to. User interest in RP's come and go, but this is not reflected in the OP's database. After a couple of years use, each user is likely to have some thousands of RP entries associated with their identity in the OP's database, while the user may only have active interest in a fraction of these. You're free to publish the RDF for the attributes you support... then they are reference-able aren't they? My point was that attributes does not have a canonical identifier that can be passed on to someone else who might put the attribute to better use. As far as I can see, the wheel more or less has to be reinvented each time someone wish to exchange attribute references (unless someone outside OpenID standardize the exchange process). Regards, Anders Feder ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
Anders, On 4/3/07, Anders Feder [EMAIL PROTECTED] wrote: Rowan Kerr skrev: The RP can send an update_url to the OP when it fetches the attributes, so it will get new values when the user changes them at the OP. But the RP can't know if the update_url is honored, i.e. if it will ever receive any updates from the OP. 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 ... When I update my information at a new OP how about some way to tell the RP it is the most authoritative. Not sure if this should be taken care of at the application or protocol level, I'd like to see it in the protocol though. The big concern I see with this is that anyone could setup an OP and claim to be the most authoritative source of information. One could say that OpenID should not be relied on to exchange sensitive information like bank account numbers, but 1) I think its a shame to limit a technology with such great potential, and 2) chances are that OpenID will be relied upon anyway - the sensitive transactions will just be performed longer down the chain, where they can't be checked. It will happen. I already have plans to share data far more sensitive than bank accounts and have brought the idea up to a few organizations that are at least interested in the concept. So far I have looked at layers of encryption, authorization and authentication on top of OpenID to solve this though. * If an OP fails to update an attribute, the RP will never know - no fall-backs can be implemented. Fails when? On a Store request? Yes, or if the Store request never leaves the OP server, for whatever reason. The OP could tell the user if there was a failure. This way the user can notify the RP or at least be aware of the problem. Not perfect, but it could be treated just like a bounced email or DNS update failure. Wayne -- Phone: 414.208.0808 Learn something from everybody. Some people will teach you what to do, while others will teach you what not to do. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
Dick Hardt wrote: There are two common client server design patterns. Request / Response and Publish / Subscribe. I see - I was not aware that the latter model was so well-understood in the client/server paradigm. The RP has what ever the user last gave the RP. If the user is involved in the transaction, the RP may ask the user for up to date information. Note that your concern is constrained to situations where the user is not involved. It is, but will automated transactions not make up a significant portion of the communications on the service-oriented Web? * If an OP fails to update an attribute, the RP will never know - no fall-backs can be implemented. When the data changes, the user then decides if the RP gets the data. If the user did not want the RP to get, well that is what the user decided. This is user centric after all. I see the merits of user-centricism, but what happens if a user do want an RP to receive an update but the RP is unavailable? For instance, imagine I have ordered a secret product from an RP. Before my order is fully processed, circumstances force me to move to another (postal mail) address. If the connection to the RP is not available when updating my mail address attribute on the OP, for whatever reason, the RP will send the secret package to my old address and whoever lives there now. * When updating, the OP impose a previous address structure upon the Web, regardless of how it is actually organized now. The converse would be the RP imposes an address structure on the OP on where to get the updated data. And rightfully so, because the user selects his OP based on his trust that its address structure will not change - this is the key principle in OpenID. Well, the OP would be responsible for responding to all the myriad useless RP requests for updated data if a pull model. Good point :) In most cases you are probably right, but one can imagine attributes, especially in futuristic scenarios, which are almost inherently 'pull' (like GPS data) such that translating them into 'pushes' are immensely ineffective. But I guess 'push' is per-attribute optional, in that case? information to RP's it has no direct interest in. A malicious RP may even exploit this storage space for own purposes. * The OP must donate storage space to support the distribution of The alternative would be the OP would need to donate storage to support which RPs are allowed to ask for data. Only if the user actually wish to restrict access - and the RP would not have access to this storage. Anyway, I'm convinced you have thought it through. Pull relates to push as quantum mechanics relates to relativistic physics - but very often quantum mechanics is overkill. Regards, Anders Feder ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
On Apr 3, 2007, at 9:14 PM, Wayne Pierce wrote: One could say that OpenID should not be relied on to exchange sensitive information like bank account numbers, but 1) I think its a shame to limit a technology with such great potential, and 2) chances are that OpenID will be relied upon anyway - the sensitive transactions will just be performed longer down the chain, where they can't be checked. It will happen. I already have plans to share data far more sensitive than bank accounts and have brought the idea up to a few organizations that are at least interested in the concept. So far I have looked at layers of encryption, authorization and authentication on top of OpenID to solve this though. I'd like to second this. I'm looking at using OpenID in the developing world, in the context of helping communities to transition out of being refugee camps. The hardware is a few years away from being cheap enough to use, but has many billion-dollar companies working on it (cellphones, wimax, etc.) The software, however, is much less well examined, so that's where I'm currently focussing. In these contexts, your OpenID, accessed by your cellphone, may be the hardest identity credential you have - much more trustworthy than your government issued ID, given to you by a state you fled years ago - or the interim credentials your host country provided you with. I should be getting some OSD funding to work on this idea in the next few weeks. Vinay -- Vinay Gupta - Designer, Hexayurt Project - an excellent public domain refugee shelter system Gizmo Project VOIP: 775-743-1851 (usually works!) Cell: Iceland (+354) 869-4605 http://howtolivewiki.com/hexayurt - old http://appropedia.org/ Hexayurt_Project - new Skype/Gizmo/Gtalk: hexayurt I have a proof which unfortunately this signature is too short ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
Wayne Pierce wrote: When I update my information at a new OP how about some way to tell the RP it is the most authoritative. Not sure if this should be taken care of at the application or protocol level, I'd like to see it in the protocol though. The big concern I see with this is that anyone could setup an OP and claim to be the most authoritative source of information. I agree completely. Currently, if my OP turns rogue or otherwise fail to serve me, I'm left with no recourse. A bullet-proof way of dealing with this would be with digital signatures though I sense some aversion to PKI in the OpenID community. The OP could tell the user if there was a failure. This way the user can notify the RP or at least be aware of the problem. Not perfect, but it could be treated just like a bounced email or DNS update failure. Yes, this is probably how it will be handled and it will work. I just think there will be corner cases where the user is not able to 'change course' in time. And handling corner cases sets excellent technology apart from very good technology - but it will work. Regards, Anders Feder ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
On 3-Apr-07, at 3:05 PM, Anders Feder wrote: Dick Hardt wrote: There are two common client server design patterns. Request / Response and Publish / Subscribe. I see - I was not aware that the latter model was so well- understood in the client/server paradigm. The RP has what ever the user last gave the RP. If the user is involved in the transaction, the RP may ask the user for up to date information. Note that your concern is constrained to situations where the user is not involved. It is, but will automated transactions not make up a significant portion of the communications on the service-oriented Web? * If an OP fails to update an attribute, the RP will never know - no fall-backs can be implemented. When the data changes, the user then decides if the RP gets the data. If the user did not want the RP to get, well that is what the user decided. This is user centric after all. I see the merits of user-centricism, but what happens if a user do want an RP to receive an update but the RP is unavailable? The OP can try again later. The reverse would need to be true if the OP was not available when the RP wanted to get the data. * When updating, the OP impose a previous address structure upon the Web, regardless of how it is actually organized now. The converse would be the RP imposes an address structure on the OP on where to get the updated data. And rightfully so, because the user selects his OP based on his trust that its address structure will not change - this is the key principle in OpenID. The user can change OPs if they are using delegation. Well, the OP would be responsible for responding to all the myriad useless RP requests for updated data if a pull model. Good point :) In most cases you are probably right, but one can imagine attributes, especially in futuristic scenarios, which are almost inherently 'pull' (like GPS data) such that translating them into 'pushes' are immensely ineffective. But I guess 'push' is per- attribute optional, in that case? Who has access to my GPS data is something I will want to tightly control! information to RP's it has no direct interest in. A malicious RP may even exploit this storage space for own purposes. * The OP must donate storage space to support the distribution of The alternative would be the OP would need to donate storage to support which RPs are allowed to ask for data. Only if the user actually wish to restrict access - and the RP would not have access to this storage. I think we all learned the negative aspects of having our data publicly searchable with email and spam. The FOAF camp was rolling along with the Pull model until they realized the issues around access control of the data. Anyway, I'm convinced you have thought it through. Pull relates to push as quantum mechanics relates to relativistic physics - but very often quantum mechanics is overkill. Not sure I follow the analogy. Push is actually much simpler then Pull for any kind of sensitive data, which is most of the useful attribute data. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
On Apr 3, 2007, at 16:20, Dick Hardt wrote: The FOAF camp was rolling along with the Pull model until they realized the issues around access control of the data. ... Push is actually much simpler then Pull for any kind of sensitive data, which is most of the useful attribute data. I think the archives of the OpenID mailing lists (this one and its predecessor list at Six Apart) are full of endless cycles on the push- vs.-pull argument. Funnily enough, to the best of my knowledge, so far the debate actually hasn't advanced at all since probably more than a year ago. In summary: Push is better because access control is easier and the user always needs to take a specific action to actually move data (i.e. better user control) etc. etc. Pull is better because access control is just as easy (that's what we have OpenID for!), and the only reason we have spam is because it's built on the e-mail push model etc. etc. With a long list of etc. etc. in both cases. I'd prefer if we not go back to this discussion unless somebody has a genuinely new argument. Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
