Re: experimental namespace for openid.net
+1 to http://experimental.openid.net
It would be good to add this to the repository work Breno and John are
doing as having a registry for experimental URIs would be good as well.
Thanks,
George
Dirk Balfanz wrote:
[+gene...@openid.net mailto:gene...@openid.net for a broader audience]
On Thu, Jul 9, 2009 at 4:45 PM, Dirk Balfanz balf...@google.com
mailto:balf...@google.com wrote:
Hi guys,
Google would like to launch a feature in which we're allowing our
Google Apps hosted domains to become OpenID providers. The
authentication part of it is pretty simple - Google is already
logging in users to their apps, so we can also host an OP endpoint
for those domains and send assertions back to Relying Parties.
What is more difficult is the discovery part. We have been working
with the XRI TC to define a XRD-based discovery protocol that
would allow this kind of hosting of discovery documents on behalf
of our customers.
We believe that providing proof-of-concept implementations drives
standardization processes forward, so in this spirit we want to
launch this feature in the near future, using a discovery protocol
that as far as we can tell meets all the requirements of what the
XRI TC is currently converging on, but which has not been vetted
as an official standard (it's a chicken and egg thing - without
PoC no standards, without standards by definition no
standards-compliant implementations).
While we were tossing around ideas
http://markmail.org/message/ixc5led2lobdwij2in the
standardization committees we just used random identifiers for new
XML namespaces, etc. that we would need for this discovery
protocol. Now that we're about to launch we need to decide what to
call these things. We would like to use a namespace
in http://specs.openid.net/... because we want this kind of
discovery protocol to be part of OpenID, but we can't really use
them because we don't have a next-generation discovery protocol yet.
So what should we use? How
about http://experimental.openid.net/... ? That way, Relying
Parties know that what we're trying to do is be a part of the
OpenID community and bring the protocol forward. On the other
hand, this would also be a signal to the RP that they're using a
feature that has not been vetted as a standard yet.
For example, a discovery document for a domain balfanz.net
http://balfanz.net at Google might look like this (notice the
experimental namespace and the XML elements using it):
?xml version=1.0 encoding=UTF-8?
xrds:XRDS xmlns:xrds=xri://$xrds xmlns=xri://$xrd*($v*2.0)
ds:Signature xmlns:ds=http://www.w3.org/2000/09/xmldsig#;
ds:SignedInfo
ds:CanonicalizationMethod
Algorithm=http://docs.oasis-open.org/xri/xrd/2009/01#canonicalize-raw-octets; /
ds:SignatureMethod Algorithm=http://www.w3.org/2000/09/xmldsig#rsa-sha1;
/
/ds:SignedInfo
ds:KeyInfo
ds:X509Data
ds:X509Certificate
MIICgjCCA...
/ds:X509Certificate
ds:X509Certificate
MIICsDCCAhmgAwIB...
/ds:X509Certificate
/ds:X509Data
/ds:KeyInfo
/ds:Signature
XRD
CanonicalIDbalfanz.net http://balfanz.net/CanonicalID
Service priority=0
Typehttp://specs.openid.net/auth/2.0/server/Type
Typehttp://openid.net/srv/ax/1.0/Type
Typehttp://specs.openid.net/extensions/pape/1.0/Type
URIhttps://www.google.com/a/balfanz.net/o8/ud?be=o8/URI
/Service
Service priority=0
xmlns:experimental=http://experimental.openid.net/google/2009/07/xmlns/;
Typehttp://www.iana.org/assignments/relation/describedby/Type
MediaTypeapplication/xrds+xml/MediaType
experimental:URITemplatehttps://www.google.com/accounts/o8/user-xrds?uri={%uri}
https://www.google.com/accounts/o8/user-xrds?uri=%7B%uri%7D/experimental:URITemplate
experimental:NextAuthorityhosted-id.google.com
http://hosted-id.google.com/experimental:NextAuthority
/Service
/XRD
/xrds:XRDS
What do you guys think?
Dirk.
___
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: OAuth Hybrid and UI ML?
Will these lists be open for reading to the community? I'd like to keep up with what's happening in both these groups. Thanks, George David Recordon wrote: Once the working groups are approved and someone is willing to moderate new members on the list to make sure they've signed contribution agreements before posting, I can make the list itself. --David On Jun 11, 2009, at 6:21 PM, Allen Tom wrote: Hi Nat, How does one create a mailing list? At least with regards to the OpenID UI WG, we're just mailing each other directly. Allen Nat Sakimura wrote: Hi. I just found out that the Mailing list for OAuth Hybrid WG and UI WG are not listed on http://openid.net/mailman/listinfo/ . http://openid.net/mailman/listinfo/ To make sure equal participation, we should make it possible for people to find out about them. Are they established at all? Where is the discussion being conducted right now? -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net mailto:specs@openid.net 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: Should we recommend that return_to url is always HTTPS? What about realm?
John, By PPID do you mean the InfoCard unique User:RP identifier? Or are you referring to the use of pseudonymous identifiers within OpenID? If the latter, I didn't see the thread that was suggesting that the pseudonymous identifiers match the realm. I would be against that suggestion. The spec requires the RP to do discovery on the pseudonymous identifier to prove that the OP that returned the response is authoritative for the pseudonymous identifier. With this mechanism, the realm should not need to match the identifier. Thanks, George John Bradley wrote: Luke, From a URI point of view the two URI are different and it can't be considered steeping up security. I understand that is what would normally happen but it violates some basic principals. It also compromises RP discovery. A wijldcard in the realm may be the better solution. Though you may not want to include matching all protocols. In the other thread we are discussing PPID like identifiers. If they are based on the realm as people are discussing, introducing wildcards etc introduces the question of realm normalization on that side. John Bradley On 14-May-09, at 11:25 AM, Luke Shepard wrote: So, RP delegation sounds like a very general solution to the problem, and seems okay to push for. But I think there’s a much simpler solution that solves the specific problem I described below: RULE: If the realm is http, then the return_to can be either http or https. So this would be legal: realm: *http*://open.lukeshepard.com/ return_to: *https*://open.lukeshepard.com/openid/receiver.php This would NOT be legal – you can’t go the other way. realm: *https*://open.lukeshepard.com/ return_to: *http*://open.lukeshepard.com/openid/receiver.php So, the receiver should be allowed to INCREASE its security level from the realm, but not decrease. This is analogous to wildcards for the protocol instead of just subdomain. Another alternative would be to have explicit wildcards for the protocol, or to allow realms with relative protocols, like: explicit wildcard: *://open.lukeshepard.com relative protocol: //open.lukeshepard.com On 5/14/09 7:19 AM, John Bradley jbrad...@mac.com wrote: I agree that RP delegation should be possible and even desirable. To do that safely the OP needs to do RP discovery over SSL or discover a XRD with detached sig for the RP. Otherwise you open up Man in the Middle attacks. My point was that in the existing spec to prevent interception of tokens and attributes, the Realm that is displayed by the OP to the user needs to match where the assertion is sent. I agree that this is something that should be addressed in openID 2.1 ether for XRD with dsig or via XRDS with TLS. John B. On 14-May-09, at 12:24 AM, Dirk Balfanz wrote: I don't see why a realm shouldn't be able to delegate to a return_to URL the same way that a user id can delegate to an OP endpoint. This includes delegating from http to https, or even to a different domain altogether. Over on the XRI TC we've been talking about how to do this securely, e.g., by signing the XRD that does the delegation: http://wiki.oasis-open.org/xri/XrdOne/XmlDsigProfile Dirk. On Wed, May 13, 2009 at 7:43 PM, John Bradley jbrad...@mac.com wrote: Luke, Realm was called trust_root in 1.1, and is a bit like audience restriction in SAML. It is the display version of the return_to, and also used for RP discovery by the OP. I am not certain what the problem is with it being https: if the return_to is https:. There is explicitly no connection to be inferred by DNS authority between URI differing in scheme. Differentiating TLS by its own scheme is a decision we have to live with. The user should consent to authentication for the site they are logging into. http://open.lukesheppard.com and https://open.lukesheppard.com could be different sites. If the RP has both HTTP and HTTPS the best practice would be to always use the https: version for realm so that RP discovery cant be spoofed via DNS. Regards John B. On 13-May-09, at 2:10 AM, specs-requ...@openid.net wrote: Date: Tue, 12 May 2009 23:10:38 -0700 From: Luke Shepard lshep...@facebook.com Subject: Should we recommend that return_to url is always HTTPS? What about realm? To: OpenID Specs Mailing List specs@openid.net Message-ID: c62fb26e.bce7%lshep...@facebook.com mailto:c62fb26e.bce7%25lshep...@facebook.com Content-Type: multipart/related; boundary=_004_C62FB26EBCE7lshepardfacebookcom_;
Re: Should we recommend that return_to url is always HTTPS? What about realm?
OK, thanks. I think I understand how you are relating realm to PPID. I agree that we probably have to generate the PPIDs on the user:realm pair (note, it would be very nice if realm were included in the association request; but that's a different discussion). Even this causes some problems if a set of RPs share the same realm... but it's the best that can be done right now with the current spec. While realm normalization isn't required for PPIDs to work and be unique, practically we'll have to do something so that users have a least a chance of a consistent experience. Note that this will pretty much require an RP to never change their realm because if they do, all the PPIDs will regenerate and the user's data will be lost. Thanks, George John Bradley wrote: George, By PPID I am referring to a pairwise pseudonymous identifier like PPID in info-card or the IDs Google uses. The 2.0 spec talks about OP identifiers being used to allow the user to select an identity at the OP. (badly and in a confusing way) No place in 2.0 talks about pseudonymous identifiers of any sort. So the question is if the user doesn't want there activity correlated, or a RP for PII legal reasons doesn't want a correlatable identifier for the user how should the OP produce such an identifier. Further if that type of identifier is required by the RP how would they indicate that. The realm would only be used by the OP to produce the private personal identifier. Doing this raises additional questions about how to normalize the Realm. Do you want to produce the same PPID for all of these? http://example.com http://www.example.com https://www.example.com http://www.example.com:80 http://www.example.com:443 https://www.example.com:443 http://www.example.com/ The RP might so to make it at least predictable there should be some normalization rule. I am sure Breno will jump in I know this is one of his issues. So while all openIDs are on some sense pseudonymous, I was referring to the pairwise ones. Regards John B. On 14-May-09, at 1:17 PM, George Fletcher wrote: John, By PPID do you mean the InfoCard unique User:RP identifier? Or are you referring to the use of pseudonymous identifiers within OpenID? If the latter, I didn't see the thread that was suggesting that the pseudonymous identifiers match the realm. I would be against that suggestion. The spec requires the RP to do discovery on the pseudonymous identifier to prove that the OP that returned the response is authoritative for the pseudonymous identifier. With this mechanism, the realm should not need to match the identifier. Thanks, George John Bradley wrote: Luke, From a URI point of view the two URI are different and it can't be considered steeping up security. I understand that is what would normally happen but it violates some basic principals. It also compromises RP discovery. A wijldcard in the realm may be the better solution. Though you may not want to include matching all protocols. In the other thread we are discussing PPID like identifiers. If they are based on the realm as people are discussing, introducing wildcards etc introduces the question of realm normalization on that side. John Bradley On 14-May-09, at 11:25 AM, Luke Shepard wrote: So, RP delegation sounds like a very general solution to the problem, and seems okay to push for. But I think there’s a much simpler solution that solves the specific problem I described below: RULE: If the realm is http, then the return_to can be either http or https. So this would be legal: realm: *http*://open.lukeshepard.com/ return_to: *https*://open.lukeshepard.com/openid/receiver.php This would NOT be legal – you can’t go the other way. realm: *https*://open.lukeshepard.com/ return_to: *http*://open.lukeshepard.com/openid/receiver.php So, the receiver should be allowed to INCREASE its security level from the realm, but not decrease. This is analogous to wildcards for the protocol instead of just subdomain. Another alternative would be to have explicit wildcards for the protocol, or to allow realms with relative protocols, like: explicit wildcard: *://open.lukeshepard.com relative protocol: //open.lukeshepard.com On 5/14/09 7:19 AM, John Bradley jbrad...@mac.com wrote: I agree that RP delegation should be possible and even desirable. To do that safely the OP needs to do RP discovery over SSL or discover a XRD with detached sig for the RP. Otherwise you open up Man in the Middle attacks. My point was that in the existing spec to prevent interception of tokens and attributes, the Realm that is displayed by the OP to the user needs to match where the assertion is sent. I agree that this is something that should be addressed in openID 2.1 ether for XRD with dsig or via XRDS with TLS. John B. On 14-May-09, at 12:24 AM, Dirk Balfanz wrote: I don't see why a realm shouldn't be able
Re: Requiring Pseudonymous Identifier
+1 to using AX and the identity-less flow Andrew identified recently for claims/attribute based access to web sites. There are some 3rd-party asserted issues in regards to the validity of the attribute value but that's a whole different discussion:) Thanks, George Luke Shepard wrote: Agreed. If all you want is a group, then I’d think that the response would just not include an identifier. You could use an extension, perhaps AX, to request information about the group a user belongs to. For example, if you wanted to understand company membership, you could request and return only http://axschema.org/company/name. On 5/12/09 11:08 PM, Martin Atkins m...@degeneration.co.uk wrote: Chris Messina wrote: So, imagine I use directed identity in a school application... when I sign in to the OP, it will return something like schoolname.edu/student as the identifier. Overloading our existing concept of an identifier to support identifying a group worries me. Most consumers expect an identifier to be for a person and are designed around this principle. I think if groups are useful their design should be different such that consumers are able to distinguish between a user and a group. ___ specs mailing list specs@openid.net 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: Requiring Pseudonymous Identifier
I'm perfectly fine with using RP discovery as a mechanism for the RP to specify what policy it requires. I believe that unsolicited assertions are going to become more common, so we need to support it. What I don't want OpenID to do is specify the actual syntax of the pseudonymous identifier. I agree that the RP has to trust the OP (in some sense) or make it's own determination that the OP is not honoring the RP's wishes and then take some action. For RP's behind firewalls, it would be nice to allow them some mechanism other than RP discovery to assert their requirements, but that should preclude the discover option. Thanks, George Andrew Arnott wrote: leaves out the scenario of unsolicited assertions.A new directed identity value that the RP passes to the OP to indicate it wants a psuedononymous identifier. Consider this: An OP needs to perform RP discovery (already), and probably does so before sending an unsolicited assertion in order to find out what the assertion receiving URI would be for a given realm. DNOA does this already. If that RP's XRDS document included a TypeURI element that had a special psuedononymous-identifier-only-please value the OP could pick up on this, and send the unsolicited assertion using the appropriate type of claimed_id. Likewise, when an RP sends an ordinary directed identity request to an OP, the OP would again notice the RP's XRDS during RP discovery and see what kind of identifier the RP wants and assert accordingly. Yes, some OPs won't honor the RP's wishes, and some OPs don't do RP discovery at all. Perhaps to help the RP detect whether the OP respected its wishes would be to send a PAPE extension or some other openid.* parameter to say yes, this is a pseudo- identifier. RPs have no way to analytically be certain that some identifier is psuedononymous anyway, so ultimately the RP has to trust the OP (whether implicitly or through a white list is up to the RP). -- Andrew Arnott I [may] not agree with what you have to say, but I'll defend to the death your right to say it. - Voltaire On Wed, May 13, 2009 at 8:44 AM, George Fletcher gffle...@aol.com mailto:gffle...@aol.com wrote: I don't think OpenID should specify how pseudonymous identifiers are generated. That should be up to the OP. But I like the idea of using a fixed URI as the claimed_id value to specify the behavior desired by the RP. If, however, we need to grow this to cover anonymous based identifiers (i.e. the claims based models from earlier in this thread) then it might make sense to look at a PAPE extension that covers the type of identifier requested. Thanks, George Nat Sakimura wrote: Sorry for a slow response. This week is especially busy for me... I borrowed the notion from Austrian Citizen ID system. In there, the services are divided into sectors. A sector may span several agencies. They call ID as PIN (Personal Identification Number). There is a secret PIN (sPIN) which is not used anywhere but in their SmartCard. Then, sector sepcific PIN (ssPIN) is calculated in the manner of : SHA1(sPIN + SectorID) (Note, there is a bit more details but...) I have thrown OP secret into it. To avoid the analytic attack, I agree that it is better to use individual secret, as some of you points out. Regards, =nat On Tue, May 12, 2009 at 5:55 PM, Dick Hardt dick.ha...@gmail.com mailto:dick.ha...@gmail.com wrote: On 12-May-09, at 1:36 AM, Nat Sakimura wrote: Reason for using RP's Subject in XRD instead of simply using realm is to allow for something like group identifier. would you elaborate on the group identifier concept? This is just one idea. Downside of this approach is that we need to set up a WG. I am sure there are more ideas. It might be possible to utilize AX so that it will only be a profile that does not require a WG. So shall we start discussing which direction we want to go forward? sure! ___ specs mailing list specs@openid.net mailto:specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposing an OpenID Authentication 2.1 Working Group
Great notes! Thanks! Martin Atkins wrote: Here's the output from today's IIW session on this: 2.0 has been finalized bunch of implementations found lots of spec bugs also gone and done oauth and email addresses and other things. Can we support these in the core spec? - Making the spec more readable and fixing bugs (eratta) - Delegation - Error handling - Adding a security appendix - could be a separate document referred to by the spec - possibly produced by separate group - Who controls this security page? - Security committee could look after this. - or Allen at Yahoo! will be editing a security document - Clarifying XRI - Currently there's no firm message about whether RPs MUST support XRIs or not. - Need to clarify how exactly XRI should be used with OpenID. - Similar to the whitelist question. - Clarify if RPs can white or blacklist what OPs they accept, and vice-versa. - Discovery of type of identifiers an RP supports. - Clarifying IRI - Updating discovery. Possibly including the new-fangled XRD discovery. - Clarifying whether association over SSL must/can use diffie-hellman. - Discovery of support of checkid_immediate. Exploratory work: - Signature mechanisms. Looking at additionally supporting the mechanisms defined in OAuth so that they can be closer together. - Possibly deprecating the current signature mechanism. - Public keys? - Email-shaped identifiers for OpenID - Could be a separate working group? There was consensus that email-shaped identifiers would be worked on by a separate group and possibly rolled into 2.1 if it's done in time. - Smart/rich clients? - Could be in this WG unless it ends up being a big change in which case it could be its own WG. - There's another session about this. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Chief Architect AIM: gffletch Identity Services Work: [EMAIL PROTECTED] AOL LLC Home: [EMAIL PROTECTED] Mobile: +1-703-462-3494 Office: +1-703-265-2544 Blog: http://practicalid.blogspot.com ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: This is user's URI for Assertion Quality Extension
(learned from Sun's implementation) is I am a member of Sun but you don't know who. Is this the only variation of OpenID services that any company will ever come up with? I'm thinking here of membership levels, such as This employee is technical support, this employee is sales. and This employee works at an entry-level position, this employee is a manager. - all of which may be better suited to AX with the OP not letting its users set their own attributes, and since many sites either wouldn't use the granularity or wouldn't need it, there's not much reason here for sticking it in the Assertion Quality spec. But we could start out with the 3 distinctions known, and add others only if they became appropriate. Even in the 3 distinctions you've identified, could they be handled by AX? That seems to me to be the natural fit. Even in the case of what SUN did, I think AX would be better suited rather than the implicit statement that SUN made. Hmm . . . the RP could process a URI to extract OP-Local and create one account for the entire site (*if* it knew that the user's account with that OP was anonymous). Here's the challenge: in cases of sub-domains, what's the site? Is there a meaningful difference between tech.site.com and sales.site.com? I'm confused by the relationship between OP-Local and the entire site. The OP-Local identifier is the OP's identifier for the user (if it's provided). However, it's still an identifier for the individual. I suppose you could associate it with this OP is authoritative for this OpenID but I think that's about as much as can be assumed. Thanks, George -Shade At 8:17 AM -0400 9/5/08, George Fletcher wrote: SitG Admin wrote: 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?) How would the OP know if the user it's authenticating is a member at the RP? It's not required to keep that information? I suppose OPs could keep track of all the RP's they've sent a particular OpenID to... but it might not be trivial for the OP to extract that information and make a determination that a particular OpenID falls into the classifications you've listed. Also, couldn't the RP keep track of the op_local value with the claimed_id to help reduce clutter in the RP db? This would help with user entered claimed_id's. Of course in directed identity there is only one identifier, but that shouldn't change on a regular basis for the same user. 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. The spirit is for the OP to create a unique identifier for the relationship of user:OP:RP and maintain that relationship across time. 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.) 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. If you use a correlatable OpenID at our site, then we can provide you these additional benefits (e.g. automatically find people that know you that also use this site). Note that it's possible to provide these same benefits without using correlatable identifiers, but it requires a service that knows the mapping. 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
Re: OpenID Assertion Quality Extension - Draft
+1 simple and straight forward Just curious about uses cases where the required authentication level changes over time. For instance, a use case where to view my stock portfolio just requires password, but doing a trade requires voicebio. Is the expectation that authentication events can be treated as standalone? or that it's the RP's responsibility to manage the combinations based on the identifier? One final question... Is it valuable to provide a way to request two or more authentication methods be employed in the authentication event? For example, administrators of a site must use both password and hardotp. Everyone else just needs password. Thanks, George ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] OpenID Assertion Quality Extension - Draft
Paul Madsen wrote: Hi George, for your use case below, why would not the RP just ask for the user to be up-authenticated at the desired higher level when necessary? So in the draft... how does the RP ask for the user to be "up-authenticated"? The authentication request parameters do not in any way indicate a previous authentication, and the extension parameters also don't include any way to indicate a previous authentication. That is what I really meant by the authentications being "standalone". The RP may relate the two authentications in some way because it requested both. Maybe that's good enough. Are you asking whether the RP should be allowed to ask the user to re-present their URI in order for this to happen? And thereby effectively treating each event as disconnected/standalone? Ideally, the user would not be able to change their URI when being re-challenged based on max_auth_age but I guess the RP should make sure to code for that edge case. Wrt combinations, I know from experience that the alternative to allowing for RPs to specify combinations is a combinatorial explosion in the number of mechanism identifiers. I agree that the combinations can explode... but they are also useful. For example to hack my account you need both my "password" and my "hardotp". That's two "secrets" that need to be determined for my account to be compromised. (Not that this doesn't stop phishers). Thanks, George Paul George Fletcher wrote: +1 simple and straight forward Just curious about uses cases where the required authentication level changes over time. For instance, a use case where to view my stock portfolio just requires "password", but doing a trade requires "voicebio". Is the expectation that authentication events can be treated as "standalone"? or that it's the RP's responsibility to manage the combinations based on the identifier? One final question... Is it valuable to provide a way to request two or more authentication methods be employed in the authentication event? For example, administrators of a site must use both "password" and "hardotp". Everyone else just needs "password". Thanks, George ___ general mailing list [EMAIL PROTECTED] http://openid.net/mailman/listinfo/general ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] OpenID Assertion Quality Extension - Draft
+1 Avery Glasser wrote: Actually, this could be pretty simple to implement: Replace openid.aqe.preferred_auth_mode with the following: openid.aqe.auth_factor1 Optional: The method of authentication the RP would like the OP to perform, or in the case of a multi-factor authentication, the first method that the RP would like the OP to perform. The mode should match one of the advertised values in the XRDS. If this is not specified, then any authentication method is acceptable. Value: Comma-delimited list of "none", "password", "pin", "fingerbio", "handbio", "hardotp", "irisbio", "otherbio", "smartcard", "softotp", "voicebio" Note: The OP should attempt to authenticate the user with the most secure mode requested. For example, if the OP has determined that their voicebio method is stronger than their password method and the RP requests either "voicebio or password", the OP should strive to authenticate the user by "voicebio" when possible. If the two modes are considered equally strong, then it is the choice of the OP regarding which one or ones to authenticate against. OPs should note that authenticating a user by a non-preferred method may result in an RP denying access. openid.aqe.auth_factor2 Optional: In the case of a multi-factor authentication, the second method that the RP would like the OP to perform. The mode should match one of the advertised values in the XRDS. If this is not specified, then any authentication method is acceptable. If this is not specified, it is assumed that the RP is requesting only a single factor for authentication. The OP will not use the same method for this factor as was used in any previous factors. For example, if the first factor is a password, the second factor cannot also be a password. Value: Comma-delimited list of "none", "password", "pin", "fingerbio", "handbio", "hardotp", "irisbio", "otherbio", "smartcard", "softotp", "voicebio" Note: The OP should attempt to authenticate the user with the most secure mode requested. For example, if the OP has determined that their voicebio method is stronger than their password method and the RP requests either "voicebio or password", the OP should strive to authenticate the user by "voicebio" when possible. If the two modes are considered equally strong, then it is the choice of the OP regarding which one or ones to authenticate against. OPs should note that authenticating a user by a non-preferred method may result in an RP denying access. openid.aqe.auth_factor3 ... you can figure how it would continue. There are very few use cases that would use more than two factors. So, in this case, if you want the user to authenticate with two factors, first with a password and second with a securID or voice biometric print... openid.aqe.auth_factor1 = "password" openid.aqe.auth_factor2 = "hardotp", "voicebio" conversely, if you want two factors, which could be any combination of password, hardotp or voicebio in any combination: openid.aqe.auth_factor1 = "hardotp", "voicebio", "password" openid.aqe.auth_factor2 = "hardotp", "voicebio", "password" the response from the OP, assuming that it followed the request from the RP would look like openid.aqe.auth_factor1 = "password" openid.aqe.auth_factor2 = "hardotp" I would think that this is clear enough that we could make the small change to the spec to allow for this type of methodology. Thoughts? - Avery ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Making identities persistent?
I believe it's possible to prevent impersonation for the use case where the user instructs their IdP (OP) to inform the RP of the identifier change. However, this will only work if the RP remembers the IdP that last authenticated that OpenID identifier and only allows this message from that IdP. Thanks, George P.S. Functionally, this seems similar to the SAML ManageNameIDRequest message. Hallam-Baker, Phillip wrote: Don't forget that the a more important constraint here is to prevent impersonation. I don't see how one can switch between genuinely autonamous IdPs in the way suggested without allowing a rogue IdP to impersonate anyone they chose. At what point do the synchronization mechanisms you build in exceed the complexity of PKI? -Original Message- From: John Kemp [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 01, 2006 11:33 AM To: Hallam-Baker, Phillip Cc: Stefan Görling; Shutra Zhou; specs@openid.net Subject: Re: Making identities persistent? Hello, I think you need the ability for a user to change his identifier at the RP (as George notes below) and also at the IdP. In addition, it should be possible for the IdP to providing OpenID "forwarding" if the user leaves for another IdP (perhaps the user will even pay for a forwarding service?) We're not talking about persistence as such (a particular users OpenID can surely change over time?), but more the ability for the user to update her OpenID when she switches from one IdP to another. At the IdP, this would I guess be kind of like leaving a forwarding address, as the user is "leaving" one IdP and moving to another. At the RP, the user is telling the RP that he is using a new IdP. So, I think George's (1) is a necessity, and agree that (2) is a business decision, but certainly offers the ability for an IdP to be "community-friendly" if it so wishes, and may even be a good business decision. Isn't this all about the likely /lack/ of persistence in a particular OpenID though? Regards, - John Hallam-Baker, Phillip wrote: If we want identities to be persistent then we are going to need to introduce a layer of indirection. This normally gets me worried about patents and such. Fortunately Multics did this, so did UNIX and VMS. Plenty of prior art. If we are serious about decentralization then map the user identifier onto a randomly assigned machine readable GUID. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Stefan Görling Sent: Wednesday, November 01, 2006 10:52 AM To: Shutra Zhou Cc: specs@openid.net Subject: Re: Making identities persistent? The reasons for raising this question was partly that I've been doing some research on how people use e-mail addresses and sad to say, you can not expect the user to make wise choices. And even so, companies go broke even the best ones. Services comes and disappear. In my research over half of the population use non-portable e-mail addresses tied to an employer, university, etc. and is likely to only live a few years. E-mail is not a stable address/identity identifier. We must not rely on it as such. If we want an identity to be persistent, it must contain a migration feature, so that I can move all their trust relations from one place to another. This of course creates a number of other issues such as security and complexibility, but it is my sincere belief that the issue should be addressed by the system and not only delegated to be dependent on wise user decisions. Therefore, my +1 is on (1) below. I will try to read back on what has been said in the past on a 'change identifier' extension and see if there is anything I can do to help. /Stefan Yes, this is important thing I thought. We should privide a spec for the consumer to change their end user's OpenID URL, optionally the end user can use multiple OpenIDs in this consuemr. And this case can be expended as this, the IdP（OpenID Server） is closed down. 2006/10/31, George Fletcher [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: This is a good use case and I think important for both us
Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
Dick Hardt wrote: What is different with OpenID vs email is that there is certainty that the user actually is the user. I'm a little confused. How is there certainty that the user actually is the user? The viability of the identifier representing the same user is dependent on the OpenID provider not recycling identifiers. Or did you just mean that in email, authentication is not always required for someone to use an email identifier? Note that the OpenID protocol does not prevent idp.spammers.com from allowing any identifier to be used and authenticated regardless of whether it's the same user or not. It is incumbent on the relying parties to determine if they will allow identifiers authenticated by a particular idp. Thanks, George ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
Dick Hardt wrote: On 20-Oct-06, at 10:14 AM, George Fletcher wrote: Of course, my expectation is that this syntax would be optional; the user can always specify their full URI identifier. I agree that this kind of an identifier is not portable, but I'm guessing that most users wouldn't know how to tweak their blog to add the necessary OpenID 1.1 HTML code to change their IDP. Most users, just use flickr for photos and if flickr supported OpenID, could potentially use some URI defined for them by flickr as an OpenID identifier. This identifier from flickr would not be very easily portable. My understanding of the proposal from David was that this was a way to discover the user's IdP, not that the email was an identifier. -- Dick Sorry to imply that email should be a valid identifier. That wasn't my intent. I'm fine with where this discussion is headed (and has headed in the past; after reading the old threads). For wide spread adoption it will be very important to have a If you're not sure what to enter, click here link on the login form to try and explain to users what they might be able to try as identifiers. My comment was really trying to speak to the issue of identifier portability. Is there an OpenID definition for this? If I have an OpenID provided by SomeSite as http://george.somesite.com, then how is that identifier portable? For it to be portable, somesite.com would have to allow me to either (a) change the HTML code of my public page (though if I read the draft 2.0 spec correctly, the HTML method is deprecated) or (b) provide some mechanism where I could change the IDP service URL returned in the XRDS document. If somesite.com does not provide either of these mechanisms, then this identifier is not portable. Also, the viability of my identifier may be dependent on the service. For instance, somesite.com may have a rule that says if I delete my SomeSite account, then they will no longer authenticate my identifier. Of course, user choice always enters in and I can choose to not use that service as my OpenID identifier provider. The i-names infrastructure does solve some of this by focusing on the identity management issues. Though here I'm paying explicitly for this portability service (along with others). Thanks, George P.S. Should this discussion get moved to the general list? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
Dick Hardt wrote: On 22-Oct-06, at 7:00 PM, George Fletcher wrote: Dick Hardt wrote: With OpenID, there is a presumption the user has selected a trust worthy IdP that will only present the user's identifiers when it really is the user. Doesn't this imply that both the user and RP have to know which IdP's are trust worthy? It is a choice by the user. Just like the user chooses with ISP to move their data, which browser to run, which OS to run. IN general, those are not dictated by the RP. I agree it is the user's choice to pick a trust worthy IDP. However, if un-trust worthy IDPs exist, and users choose them, then the RP (in order to protect itself) has to determine which IDPs it considers trust worthy. Hence both the user and the RP have to know which IDPs are trust worthy and which are not. Actually, idp.spammers.com cannot do that. The URL has metadata that states which IdP(s) are authoritative. What idp.spammers.com can do is flood an RP with a bunch of identifiers. But this is no different then a script creating new accounts on a system and is defended using the same mechanisms such as throttling and captchas. So why can't idp.spammers.com allow anyone to enter a URI of http://idp.spammers.com/name that resolves to a valid XRDS document. The RP then follows the IdP service link back to https://idp.spammers.com and does the association exchange. Now the RP re-directs the user to https://idp.spammers.com for the login page, which just re-directs the user back to the RP with the valid assertion fields. idp.spammers.com does not have to ask the user for authentication credentials (that is out of scope for the spec). For commenting on blogs this would be similar to bugmenot for web subscription services. So of course, the RP just needs to blacklist idp.spammers.com. But now we are back in the same situation we have today where its a race between spammers setting up IdPs and RPs black-listing them. I don't understand why the RP needs to do that ... is the RP wanting to do something it can't do today? No, not really. Though in most cases today the RP is also the IDP so relying on some other party to do the authentication doesn't happen too often (except within certain closely related services). There is nothing stopping the RP from looking at the URI for the IDP and not accepting it as a valid IDP. Fundamentally, trust worthiness is paramount to making the system work. For now, this means RPs will likely have some sort of ACL (black or white) for the IdPs that they deal with. The trust I am referring to is the user trusting the IdP to not let someone else impersonate them. I believe that there is also a need for the RP to trust the IdP to not allow impersonation. George: would you explain what problem you are wanting to solve so that we can deal with a concrete example? There are use cases OpenID solves today, and others require additional features that currently are not in the specification. A RP provides a personal finance service that allows users to manage portfolio information online. It also supports online bill pay services. This RP requires a set of information for the account to be created at the RP. With the current specs that RP can accept the authenticated OpenID URI and request the additional required information. Nothing different here. The issue come in the form of liability for the RP. Is the RP liable if someone gets access to someone else's information? In today's world this is the case partly because the RP is doing its own authentication. If the RP is trusting an IDP to do the authentication (plain, strong, second factor, etc) then who is liable? I suspect the RP is, though they might be able to go after the IdP. Thus the RP needs to know which IdPs are trust worthy in order to protect its liability exposure. Thanks, George ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
[Sorry for the strange posting format. I got on the list after seeing the emails. --George] First, I'm new to the list and don't want to resurface an old and long debated topic. To me this proposal is about how to make finding the user's IDP simpler using something the customer is already familiar with. Therefore, the email address format in not an identifier, but rather a way to hint to the RP both my IDP and an identifier to use at the IDP. The desire being to address current user behavior which doesn't include specifying a URI as a login mechanism. I don't use URI's at Flickr, Apple, Yahoo, Google, AOL or Microsoft. Trying to educate "the masses" to remember a new identifier, that for some is meaningless (i.e. the user might not have a blog or other URL that they are used to remembering or sharing), is difficult. As another option, the RP could present UI that has a drop down of "common IDPs" and then based on the selected "common IDP" provide another text entry for that IDP's form of identifer. However, that somewhat defeats the purpose of trying to have a very simple form entry mechanism which customers can get used to seeing and feel comfortable with. It also places a burden on the RP to keep their UI up-to-date. Of course, my expectation is that this syntax would be optional; the user can always specify their full URI identifier. I agree that this kind of an identifier is not portable, but I'm guessing that most users wouldn't know how to tweak their blog to add the necessary OpenID 1.1 HTML code to change their IDP. Most users, just use flickr for photos and if flickr supported OpenID, could potentially use some URI defined for them by flickr as an OpenID identifier. This identifier from flickr would not be very easily portable. Thanks, George There have been several long threads in the past about using email addresses as OpenID identifiers. The conclusion each time has been to avoid it. I don't remember all the arguments, but among them are: * Privacy: the last thing many users want to give a website is their email address. * Reassignability: email addresses are not only reassignable, but for some domains, they are notoriously short-lived identifiers. * Non-portability: unless you own the top-level domain, they aren't portable. Food for thought... =Drummond -Original Message- From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf Of Recordon, David Sent: Thursday, October 19, 2006 6:46 PM To: specs at openid.net Subject: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers In meeting with a large service provider this week, an issue around end user usability came up. The concern they expressed was that users are know how to enter usernames or email addresses to initiate the login process. While directed identity allows the user to enter "example.com", they feel that it still is a bit of a stretch at this time for any major deployment of OpenID. The proposal we came up with was within the spec describing what to do if someone were to enter "user at example.com" in a Relying Party's OpenID login form. The idea is that the RP splits the string on the "@" and then treats "example.com" as the IdP Identifier. This thus doesn't actually require any changes to the protocol itself. Any Relying Party can do this today, but they desire to see this as part of the specification itself so they wouldn't be doing anything special. Within the http://www.lifewiki.net/openid/ConsolidatedDelegationProposal proposal, in case one, openid.identity would be set to "http://openid.net/identifier_select/2.0" and then instead of openid.portable being empty, in this case "user at example.com" would be sent to the IdP. While not perfectly mapping to the definition of the openid.portable field, it doesn't seem like that much of a hack to do this. While I certainly am not looking to re-kindle the "Why a URI?" debate, http://[EMAIL PROTECTED] is also technically a valid URI. It is used in many cases by browsers to provide a username when making a web request. So while this is a little funky, I really think the increased usability offered by describing what a RP should do when a string like this is entered seems to outweigh the potential conceptual confusion. Thoughts? --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
It might create some confusion depending on the audience. For the audience that doesn't run their own web server, or have their own blog, it might be confusing to enter a URI. This approach would help those users make the transition without restricting the users who do get it from entering URIs. It also provides a simple way for RPs to appeal to a larger set of users (e.g. my mother-in-law wouldn't understand what to enter if asked for a URI based identifier). Thanks, George P.S. Hopefully I've got Thunderbird sending plain text messages now so they don't get scrubbed in the archives. Sorry about that. Recordon, David wrote: Yes, potentially. It is a bit of a hybrid approach I guess. --David -Original Message- From: Jonathan Daugherty [mailto:[EMAIL PROTECTED] Sent: Friday, October 20, 2006 12:59 PM To: Recordon, David Cc: Drummond Reed; specs@openid.net Subject: Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers # The thing is they aren't really giving them their email address. # Rather an identifier which looks like an email address to a user and # in some cases may also be an email address. Isn't that likely to create a lot of confusion? -- Jonathan Daugherty JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
