Re: This is user's URI for Assertion Quality Extension
SitG Admin wrote: http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html I'd like to see the 4th draft of this include a URI level authentication property. I'd like to know whether the OP is asserting that the user is a member of Site, is this specific user *at* Site, or is a member of Site and we've generated this unique Directed Identity for them that won't reveal their userID at Site but will allow you, the RP, to distinguish between this anonymous Site user and other anonymous Site users. What's the use-case? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: This is user's URI for Assertion Quality Extension
What's the use-case? If the RP doesn't care about distinguishing between users that have accounts at a site but identify themselves as such anonymously, it can reclassify them as users that have accounts at a site, consolidating what could be a large number of identities into a single account. (This is largely a convenience for the Relying Parties, reducing database clutter but perhaps the performance hit wouldn't be noticed anyway?) RP's may want to discriminate between users that use a real URI and those that only use OpenID anonymously, just as users may want to experiment with new sites using a unique (randomly generated) URI that can't be associated with their accounts elsewhere, and then use their main URI if they decide they like the RP's services. (I'm hoping that others here will volunteer their own specific use-cases or what they *could* do with such information were it asserted by an OP.) One form of discrimination could be encouraging users to have a real URI by giving them more features - reward them for adapting to the Web 2.0 model and using their OpenID around the web. Another could be swifter expiration of new accounts under the presumption that new users who use an anonymous URI are just experimenting with the service (this would be both a performance convenience for RP's as described above, and a complement of the encouragement more immediately above, instead *dis*-couraging users from using an anonymous URI for long-term use). (Since a user could still create multiple accounts on one or more sites and use each of them as a real URI; such discrimination wouldn't reduce the user's ability to compartmentalize their identity and maintain privacy.) -Shade ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: This is user's URI for Assertion Quality Extension
Hi Shade, AQE has long ago been deprecated in favour of PAPE paul SitG Admin wrote: http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html I'd like to see the 4th draft of this include a URI level authentication property. I'd like to know whether the OP is asserting that the user is a member of Site, is this specific user *at* Site, or is a member of Site and we've generated this unique Directed Identity for them that won't reveal their userID at Site but will allow you, the RP, to distinguish between this anonymous Site user and other anonymous Site users. -Shade ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.6.16/1651 - Release Date: 04/09/2008 6:57 AM -- Paul Madsene:paulmadsen @ ntt-at.com NTTp:613-482-0432 m:613-282-8647 aim:PaulMdsn5 web:connectid.blogspot.com ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: This is user's URI for Assertion Quality Extension
Hi Shade, AQE has long ago been deprecated in favour of PAPE Hmm . . . looks like PAPE is more of *how* the user was authenticated than the *quality* of their authentication (the latter seemed appropriate for what quality of identity the RP should take the OP as asserting). Looking at the specs list to find a more suitable spec to propose this for, I notice that AQE isn't even on it. It may be worth mentioning that I looked at AQE because someone suggested it to me during a discussion on the general mailing list. I can't see this going with anything (currently on the list) but Attribute Exchange, which is freely extensible, so there wouldn't be any need to change the spec for such assertions to happen. Thinking of how I might be able to set up examples of this, another possible use-case just occurred to me: This is me with my coder hat on. This is me with my manager hat on. This is me with my sales hat on. All of these would be set with AX to indicate, per specific login, in what capacity I was acting at that particular time. It might be set automatically by the software, looking at what department I was working in at the moment and whether I was on my lunch break (This is me as a regular person.) to let the OP remain solely responsible for OpenID's (and let the user not have to use their personal OpenID's at the surveilled company) but signal when an employee was not representing the company, but acting only of their own accord. The company wouldn't need to assign a different OpenID to that employee just to reflect a different stature. -Shade ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: This is user's URI for Assertion Quality Extension
All of your use-cases here seem to be to do with the RP somehow discriminating against users that have a flag set. There's a new use-case type in my reply to Paul Madsen. By the way, I'm concerned about your phrasing there. By saying that the RP discriminates *against* such users, it implies that the only difference users will see is a negative. This is most definitely NOT the case, since less database clutter will result in faster lookup times for ALL users (though, again, I do not know if such speed differences would be discernible by anyone in real-time). With that in mind, what's the incentive for the OP to actually set the flag? What service would it provide to their users? Apart from the new use-case referenced above, it's a way for the OP to ensure that RP's treat the real OpenID's *as* real. I suppose I could detect Directed Identity and say Please don't do this, enter your actual URI instead., but then the user *can't* use an anonymous ID (without at least one more click if I let them resume as usual), and if they've become accustomed to Directed Identity (or never learned how to enter their URI!), it'll interrupt the flow for them. (Kind of like the situation we have now, where users gleefully charge out to use their OpenID's and then say Hey wait, where's my login screen for OpenID? because there aren't many sites which support OpenID but trust anyone else's OP.) This would only be a reactive measure, though, for RP's refusing to treat Directed Identity as a *real* Identity. How much of the RP's trusting OP's issue is a reluctance to embrace the web 2.0 model of user-centric identity? Could the OP offer its users increased acceptance at [such] RP's by marketing to those RP's that an anonymous URI marks a unique user:OP:RP relationship that identifies the user as one of that site's human assets (not an entity unto themselves) and merely provides a way of distinguishing them from other human assets currently held by the site? -Shade ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: This is user's URI for Assertion Quality Extension
SitG Admin wrote: I've quoted your entire message below my reply since you appear to have sent your message to me directly and not to the list ;) oops... sorry How would the OP know if the user it's authenticating is a member at the RP? Not a member at the RP, a member at the OP (or any site the OP is a proper authority for). So in some cases, an OP is a proper authority for multiple SPs but that isn't in any way required. If the OP asserts an OpendID, then that OP is authoritative for that OpenID. If the user choses to use an opaque identifier, that's the user's choice and I don't think it should be circumvented. Also, couldn't the RP keep track of the op_local value with the claimed_id to help reduce clutter in the RP db? I'm not clear what you're suggesting here. I did consider a different table for each 2nd-level domain to organize the database by so a zillion users from one site didn't make things worse for the rest, but decided against it because users would come from all over the place if they followed the spirit of OpenID (specifically: decentralization). Using a different table but still having a zillion entries (one per OP-Local at a single site the OP was vouching for) when it's possible to give all those users the same account (just one in the database) is wasteful and inefficient. Per the 2.0 spec... OP-Local Identifier: An alternate Identifier for an end user that is local to a particular OP and thus not necessarily under the end user's control. also.. the OP-Local identifier may be specified in the positive response from the OP openid.identity Value: (optional) The OP-Local Identifier Note: OpenID Providers MAY assist the end user in selecting the Claimed and OP-Local Identifiers about which the assertion is made. The openid.identity field MAY be omitted if an extension is in use that makes the response meaningful without it (see openid.claimed_id above). So I was thinking that the RP could use openid.identity value as a way to track slight variations in the claimed_id based on what the OP returns. This probably wouldn't work for all OP's but could help cut down on the clutter. Yes, the OP can hand out a totally random identifier each time the user logs in, but that isn't the spirit of directed identity. That's the impression I've gained from Yahoo!'s implementation ;) I expect other OP's to improve upon the example set (nonsensical strings of alphabetical characters) in future, whether random and anonymous was Yahoo's intent or not. Actually, Yahoo generates one and only one random string for the user's OpenID and never changes it (at least that was their initial implementation). I'm sure Allen will correct me if I'm wrong:) However, the intent of the directed identity feature is that an OP would generate a unique string for the user for each RP they logged in to. This ensures that the RP's can't correlate information about the user without the user's consent. This is a key privacy feature of the 2.0 spec, but one not realized much (yet) in practice. The spirit is for the OP to create a unique identifier for the relationship of user:OP:RP and maintain that relationship across time. Ahh, okay, now I get it. You said *each time* the user logs in, not just each time at a new RP. Sorry for causing confusion. Generating a unique OpenID at each login is possible with OpenID but not implemented in any OpenID Provider that I know of. So the behavior I would expect would be the unique user:OP:RP identifier. I'm not concerned about one-time-only accounts. (If that were the case, it'd all be handled in session once someone authenticated with OpenID at all, and they'd never *have* an account. Come to think of it, that's how I was handling it in the first place.) I'm concerned about short-term relationship across time accounts that were only ever intended to maintain their relationship across a *very short* period of time. There are other reasons for proposing this, of course, but the preceding explanation focuses on new anonymous OpenID each session versus new anonymous OpenID for each user:OP:RP relationship. Do you have a use case for the short-term 'relationship across time' accounts? I can see value in a verified identity token (see my blog, http://practicalid.blogspot.com) but if the concern is cleaning up inactive accounts, could that be handled in the TOS such that an account that is inactive for n months is automatically removed? This would allow you to keep your databases fairly clean. Maybe I missed the point. So I can see a use case for an RP to know the real identifier for linking data for the user at the RP with other data by that user across the web. This seems to me to be the benefit to put before the user. Not just identity correlation, but more granular identity - I've only been able to think of 3 distinctions all sites have, but one of those
RE: This is user's URI for Assertion Quality Extension
None of them were assumed by me; I don't consider the use-case to rely on any of them. 1) A directed identity URI creates a situation where the RP *doesn't know* whether it is a real URI or not. (This assumption has been hypothetically mitigated by an idea that occurred to me during this discussion, of performing discovery on the asserted URI as normal and looking for any OpenID headers.) 2) There are other reasons for using Directed Identity (such as being able to give all users the same URL to use instead of asking them to figure out what a URL would look like with their username substituted for the example text), reasons that have nothing to do with privacy. RP's may, at their discretion, encourage use of Directed Identity (adoption of the feature, where offered at the site hosting user's URI) by treating those who *don't* use it (when available) as second-class citizens! Or just ignore (not even request, really) this information completely. Like any of the other quality assertion strings (biometrics, phone), it's not there because ALL the Relying Parties MUST use it, but because *some* of us *may* want to. Whether a RP discriminates and whether it's for or against is not dictated by this proposal. 3) Do you know what the web will look like if no user ever employs the same URI at more than one site? The same walled gardens we have right now, that's what. One account per site. OpenID doesn't provide Identity in any meaningful way (and certainly not Open) if we don't see users employing at least one URI on at least two sites. Providing the means to detect when they're using a unique URI over the long term, so they can at least be educated about the implications (if not encouraged to practice a consistent URI), does not strike me as a bad thing. -Shade ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: This is user's URI for Assertion Quality Extension
Shade, here's the nut of the problem: directed identity in OpenID Authentication 2.0 means nothing more than: The user logging in to your site is not asserting the URI they have typed in; instead the OP will tell you the URI for the user. Then _any_ URI then returned from the OP *is* then the user's URI. For example, I could enter myopenid.com when logging into an RP, have the RP discover the myopenid.com directed identity service there, and then instruct myopenid.com to return xri://=!F83.62B1.44F.2813 as my URI (which is the XRI i-number for my i-names =drummond and =drummond.reed). So the RP would end up exactly the same identifier an RP would dicover if I logged in as =drummond. That's the way directed identity is designed to work. It's not necessarily about anonymity -- it's about letting the user choose their URI at the OP rather than typing it into the RP. So net net is I don't think there's any way to ascertain a real URI even if there was such a thing. It can and should be the user's choice what URIs he/she shares with what sites. If a site has a particular reason to know that a user has shared a particular URI with another particular site, that's different -- and the OpenID protocol could be used to prove that. But I don't think that's what you're asking. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of SitG Admin Sent: Friday, September 05, 2008 1:48 PM To: specs@openid.net Subject: RE: This is user's URI for Assertion Quality Extension None of them were assumed by me; I don't consider the use-case to rely on any of them. 1) A directed identity URI creates a situation where the RP *doesn't know* whether it is a real URI or not. (This assumption has been hypothetically mitigated by an idea that occurred to me during this discussion, of performing discovery on the asserted URI as normal and looking for any OpenID headers.) 2) There are other reasons for using Directed Identity (such as being able to give all users the same URL to use instead of asking them to figure out what a URL would look like with their username substituted for the example text), reasons that have nothing to do with privacy. RP's may, at their discretion, encourage use of Directed Identity (adoption of the feature, where offered at the site hosting user's URI) by treating those who *don't* use it (when available) as second-class citizens! Or just ignore (not even request, really) this information completely. Like any of the other quality assertion strings (biometrics, phone), it's not there because ALL the Relying Parties MUST use it, but because *some* of us *may* want to. Whether a RP discriminates and whether it's for or against is not dictated by this proposal. 3) Do you know what the web will look like if no user ever employs the same URI at more than one site? The same walled gardens we have right now, that's what. One account per site. OpenID doesn't provide Identity in any meaningful way (and certainly not Open) if we don't see users employing at least one URI on at least two sites. Providing the means to detect when they're using a unique URI over the long term, so they can at least be educated about the implications (if not encouraged to practice a consistent URI), does not strike me as a bad thing. -Shade ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
