RE: OpenID Provider Authentication Policy Extension
Thanks, definitely am! Just catching up on a lot of email now. --David -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Friday, July 13, 2007 11:05 AM To: Recordon, David Cc: specs@openid.net Subject: Re: OpenID Provider Authentication Policy Extension David, On 22-Jun-07, at 9:46 AM, Recordon, David wrote: So please, check it out and let me know what you think...especially around the questions in the Editorial Comments section at the end. http://openid.net/specs/openid-provider-authentication-policy- extension- 1_0-01.html Hope you're still welcoming feedback on this.. While trying to explain what PAPE is/does, I noticed that the term 'authentication policy' is not explicitly defined in the spec (and how a policy differentiates from a specific authentication mechanism). A clear definition could help eliminate confusion between the two. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: OpenID Provider Authentication Policy Extension
1) I imagine the URLs will become live at some point. :) 2) I wouldn't mind renaming it to no-shared-secrets which can also have a corresponding less secure policy of shared-secret-second or something like that which means the user provided a shared secret only after first providing something like a client side certificate. Also, the URLs are versioned (by date) which allows their definitions to evolve. 3) Like the http://schemas.openid.net/pape/policies/2007/06/none approach, it was required so a RP could tell the difference between a Provider not supporting the extension in the response versus not using any policies. 4) Yeah. Thanks, --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hans Granqvist Sent: Friday, June 22, 2007 3:50 PM To: Recordon, David Cc: specs@openid.net Subject: Re: OpenID Provider Authentication Policy Extension A few comments: * Would be great if all the namespace URLs resolved into live links. It always helps in the XML world and probably would in here too. * Section 4 Defined Authentication Policies We've talked about this before, but I just want to restate that it is a bad idea to name a policy based on its inferred values. Phishing-resistant implies a quality that is not necessarily measurable. Quality can also shift over time. The other policies are measurable (you can count number of factors used, for example). I'd strongly advise renaming phishing-resistant to something like no-secrets-shared (you can probably come up with a more succinct term) * 5.2 response params Requiring openid.pape.auth_policies to have a null value if no policies were met seems odd (and it may break processing where a value is always expected by the parser). Better would be to explicitly state that no policies were met by a predefined literal or URL. For example openid.pape.auth_policies=http://schemas.openid.net/pape/policies/2007/0 6/none * Section 7 Examples I wanted to see some examples on how PAPE is used in the messages. Maybe add a few? I like the work. However, the spec is optional. I was hoping finalizing auth 2.0 would be top priority. -Hans On 6/22/07, Recordon, David [EMAIL PROTECTED] wrote: Over the past few weeks I've been working on the OpenID Provider Authentication Policy Extension which is designed to replace the work I did last year with the Assertion Quality Extension. Generally, the goal of this extension is to provide Relying Parties with more information about how the End User authenticated to their Provider. This is done by a mix of the RP requesting certain policies (such as phishing-resistant or multi-factor), the OP helping the End User through the authentication process, and then in the OpenID Authentication response including the policies that were met as well as optionally a strength level for the overall authentication. This extension doesn't speak at all toward trust of the End User or Provider, so RPs will still have to decide if they believe the information returned about the authentication in the response. So please, check it out and let me know what you think...especially around the questions in the Editorial Comments section at the end. http://openid.net/specs/openid-provider-authentication-policy-extension- 1_0-01.html http://openid.net/specs/openid-provider-authentication-policy-extension- 1_0-01.txt Thanks, --David ___ 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: OpenID Provider Authentication Policy Extension
5.1 1) Clarified. 2 3) Changed the MUST to a SHOULD, since the intent was never to restrict what a user could do. 4) Changed to Integer 5.2 1) What is the use-case for this? As the parameter always describes the policies returned in pape_auth_policies, the Provider should always know how long ago the user authenticated within the session. 2) I'm fine with time coming back instead of number of seconds. 3) Changed to integer. Thanks, --David -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Thursday, June 28, 2007 7:31 PM To: Recordon, David Cc: specs@openid.net Subject: Re: OpenID Provider Authentication Policy Extension David, On 22-Jun-07, at 9:46 AM, Recordon, David wrote: So please, check it out and let me know what you think...especially around the questions in the Editorial Comments section at the end. Here are the issues that came up while I implemented PAPE in openid4java: 5.1 Request Parameters - Is preferred_auth_policies REQUIRED? Assume yes, but not clearly spelled out. - the OP MUST authenticate the End User for this request. What if the OP / user don't want to re-authenticate, and have reasons to continue their session with the previous / old auth? (For example user changed his mind at the OP about buying the book from amazon, and declines the OP's request to re-authenticate). - The OP should realize that not adhering to the request for re- authentication... implies there is an alternative to the above (other than breaking the protocol). Maybe the MUST above should be a SHOULD? - (max_)auth_age is defined as numeric. Is there value for allowing floating-point numbers here? Would be simpler to be an integer. 5.2 Response Parameters - auth_age: What should the value be if the OP did not actively authenticate the user for the current session? Suggesting unknown as a special value for this. - auth_age: Since the message may spend a (not-insignificant) time after it's created (by the library) before it's put on the wire on the wire while it's being processed by the RP a timestamp value may be better suited here (rename it to auth_time maybe?). This way the RP will be able to determine the auth_age at any time (e.g. when it actually needs to perform the sensitive operation). Could use the formating used for nonces (from RFC3339). - nist_auth_level: Numeric value - probably was meant as integer value. Thanks, Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
FW: Identifier Liftetime (WAS: RE: [OpenID] Recycling OpenIDs)
Just food for thought some day... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Evan Prodromou Sent: Monday, June 11, 2007 5:31 AM To: openid-general Subject: Re: [OpenID] Recycling OpenIDs On Sat, 2007-09-06 at 09:47 -0400, Evan Prodromou wrote: If relying parties require some high level of authentication, we have ways to specify that. I think I should have been more specific here: the best way to solve the ID lifetime problem is to add a parameter to AQE that lets the OP specify the expected lifetime of the identifier. enroll.lifetime - integer, time in days that the OP expects the identifier to identify the current principal. Some sample values: * 0: the identifier could belong to a different principal at any time. For example, anonymous OPs or OPs where users can manually change their own identifiers to any unused value at will. * Session: the identifier will belong to the current principal for the duration of the principal's browser session. * 730: the OP recycles identifiers if they haven't been used in 2 years. * Inf: the OP's policy is that the identifier will be used for only one principal. Infinity is an ideal expectation, subject to the lifetime of the OP, of the OpenID protocol, of the Internet, and of the universe. More immediately, there may be changes to the policy in the future. Note that there is no way to specify non-zero lifetimes shorter than one day, and that the special non-integer strings Session and Inf are acceptable values. I'm actually not sure how to implement an OP that would use Session -- possibly with a browser plugin? -- but I included it for completeness. -Evan -- Evan Prodromou [EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Writeup of XRDS Canonical ID verification for URLs and XRIs
That new wording for the Yadis bit looks good to me! -Original Message- From: =drummond.reed [mailto:[EMAIL PROTECTED] Sent: Thursday, June 14, 2007 4:49 PM To: 'Johnny Bufu' Cc: specs@openid.net; Recordon, David Subject: RE: Writeup of XRDS Canonical ID verification for URLs and XRIs On 13-Jun-07, at 7:04 PM, =drummond.reed wrote: With the Yadis specification now included in section 4 of XRI Resolution Working Draft 11 (see http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris for a copy of the text of this section -- thanks to David, Johnny, and Rowan for feedback on the first draft) Johnny Bufu wrote: Drummond, A bit more feedback on the Yadis section, hope you don't mind. Absolutely not. The goal has always been to make sure it specifies what Yadis 1.0 specifies. Everyone else who cares about URL-discovery-of-XRDS, please do review the proposed text of this section, posted on the XRI TC wiki at: http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris The overview section (4.1) still says: A service hosting an XRDS document discoverable through an HTTP(S) URI is only required to support one option Which is not equivalent with the Yadis spec, 6.2.4. Initiation: This request MUST be either a GET or a HEAD request. Since the client has the option to do only GET (and the server is required to respond), the server doesn't have a choice to support only HEAD. GET is required , HEAD is optional (because of the required fallback on the client side). Got it. It was David who sent me the suggestion to word it that way, as I think he thought that the client could do either option. David, if you agree with Johnny, then I will update the text of section 4.1 to say: The protocol has two options: using an HTTP HEAD request to obtain a header with XRDS document location information (section 4.2), or using an HTTP GET request with content negotiation (section 4.3). A service hosting an XRDS document discoverable through an HTTP(S) URI MUST support the GET option, and MAY support the HEAD option. A client agent seeking to discover an XRDS document from an HTTP(S) URI MAY use either option, but MUST attempt the GET option if the HEAD option fails. Let me know if you have any feedback on this wording. extending Canonical ID verification to cover any combination of URLs and XRIs is quite straightforward. The formal proposal is now fully written up on the XRI TC wiki. The first link below is to the full page; the second takes you directly to the example section. http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification Looks ok to me. For the OpenID spec, it seems we have two options now: 1) Use canonical IDs for URLs, and reference section 11 from the XRI spec for the verification part pros: addresses recycling issue brings in a (possibly) persistent identifier, addressing issue B) here [1] cons: possible issue with defining the canonical ID (or an alternate path) for HTML discovery need to adjust how the claimed id is handled with Yadis discovery more complex than 2) (more canonical id verification paths) 2) Adopt the fragment proposal and specify it inline [2] pros: addresses recycling issue simpler than 1) cons: does not address issue B here [1] Johnny [1] http://openid.net/pipermail/specs/2007-June/001847.html [2] http://openid.net/pipermail/specs/2007-May/001767.html Agreed. Good analysis. The XRI TC had a good discussion about this extended Canonical ID verification model this morning, and we realized it actually adds some additional functionality even to XRI-to-XRI relationships. We didn't have time to complete the discussion, but we're going to proceed rapidly with the goal of incorporating it into ED03 next week. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table)
I agree that all things equal, it is reasonable to look at. I think a lot of this in terms of where stripping versus identifier storage happen depends a lot on the library and application. In Rails for example the library manages the store for associations and nonces, and the application has to modify a table to store the identifier. In the stripping case, you'd then have to create a method in your application for when you call User.identifier which strips the fragment. In the second field case, you'd then have two fields in your database to work with, also from the application level. So just not sure if there really is more or less complexity from this standpoint between the two approaches. --David -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Friday, June 08, 2007 10:15 AM To: Recordon, David Cc: specs@openid.net Subject: Re: No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table) On 8-Jun-07, at 10:02 AM, Recordon, David wrote: I'm confused as to why a RP having to not create a new DB field is a requirement when looking to solve this problem. RP's implementations already need to change to upgrade from 1.1 to 2.0 and this has never been a requirement in the past. It certainly is nice that storage changes wouldn't be needed, but I don't see it as something that should be a requirement. My feeling was that, all other things being equal, some bits of code (stripping the fragment for display purposes) which ideally would go into the library, were preferred to requiring a schema change (to store the separate token) for the RPs. Not a requirement, but a strong preference. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table)
I'm confused as to why a RP having to not create a new DB field is a requirement when looking to solve this problem. RP's implementations already need to change to upgrade from 1.1 to 2.0 and this has never been a requirement in the past. It certainly is nice that storage changes wouldn't be needed, but I don't see it as something that should be a requirement. Can someone shed some light on this for me? Thanks, --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Thursday, June 07, 2007 5:03 PM To: [EMAIL PROTECTED] Cc: specs@openid.net Subject: Re: Questions about IIW Identifier Recycling Table On 6/7/07, David Fuelling [EMAIL PROTECTED] wrote: Over the last few days I've been thinking about your Identifier Recycling proposal[2], in addition to other proposals (Tokens, etc). Assuming I understand things correctly, it seems as if a hybrid of the public/private token approach would seem to garner the most checks, per the IIW grid. Not sure if my idea is technically correct or not, so please let me know if what I'm proposing falls short anywhere. Here goes I'm not sure I understand what's public about this. If I understand it correctly, from the relying party's perspective, the user's account is keyed off of the pair of the identifier and the token. This sounds like URL + private token in that table. Am I missing something? This approach was rejected at IIW because: 1. An extra database field is required (whether or not the data is transmitted using attribute exchange) 2. There is no obvious way to tell if a user is the same user across sites (The identifier contains a secret portion) 3. Concern about depending on a secret for a user to be able to sign in to a site (David's Wordpress issue) I'm not sure which of these issues were the basis for rejecting this approach. To me, the biggest problem with it is (2) Josh ___ 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: Questions about IIW Identifier Recycling Table
The difference I see is that the current secrets can be renegotiated. If we're working with non-public fragments then they cannot be. If we're working with public fragments, then I'm less concerned. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Friday, June 08, 2007 10:29 AM To: [EMAIL PROTECTED] Cc: specs@openid.net Subject: Re: Questions about IIW Identifier Recycling Table On 6/7/07, David Fuelling [EMAIL PROTECTED] wrote: If the token is publically viewable, then losing it is not an issue. I do not share David's concern about depending on a secret, since both the relying party and the provider already need to store secrets. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Do We Agree on the Problem We're Trying to Solve?
I'm not sure if we all think we're trying to solve the same problem. The two problems that have been discussed are: A) Identifier recycling normally in large user-base deployments. i.e. insert big company needs a way to give 'TheBestUsernameEver' to a new user if it has not been used in some period of time. B) Losing control of your own domain name whether that be via someone stealing it or just that you don't want to have to pay for it forever. Have we made a decision as to if we're looking for a solution to solve both of these problems, only A, or only B? --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: The CanonicalID Approach
Hey Johnny, My understanding, though don't have the appropriate spec reference, is that the process would be: 1) User enters http://daveman692.livejournal.com 2) RP fetches Yadis doc for http://daveman692.livejournal.com 3) RP sees CanonicalID of http://www.livejournal.com/userinfo.bml?userid=1356357 3) RP fetches Yadis doc for http://www.livejournal.com/userinfo.bml?userid=1356357 4) RP sees CanonicalID of http://www.livejournal.com/userinfo.bml?userid=1356357 is itself 5) RP sees Ref of http://daveman692.livejournal.com and thus has verified that the pointer goes in both directions Will have to ask Drummond his thoughts on how fragments would be used, since this morning it isn't clear to me. --David -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Friday, June 08, 2007 10:42 AM To: Recordon, David Cc: specs@openid.net Subject: Re: The CanonicalID Approach Hi David, On 7-Jun-07, at 6:31 PM, Recordon, David wrote: You could also, don't shudder too hard Dick :), use an i-number as your persistent identifier via this method though on the flip-side could also use a fragment if that is the approach someone would like to take. The nice thing is that this method is extremely flexible in terms of what you use as your persistent identifier in different cases. The question (that we will need to specify or have a clear pointer to) is how the canonical ID verification is done. (BTW: Was this section updated on Wed in the XRI draft?) Your HTTP URL canonical ID example is straight-forward and simple. Do you have an example of how it would work with fragments, say: http://openid.aol.com/daveman692 - reassignable http://openid.aol.com/daveman692#1234 - persistent Thanks, Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Do We Agree on the Problem We're Trying to Solve?
On Jun 8, 2007, at 10:50, Johannes Ernst wrote: I would suggest that any solution to B is also very likely a solution to A. I would agree with that statement. --David -Original Message- From: Johannes Ernst [mailto:[EMAIL PROTECTED] Sent: Friday, June 08, 2007 10:50 AM To: Dick Hardt Cc: Recordon, David; specs@openid.net Subject: Re: Do We Agree on the Problem We're Trying to Solve? I would suggest that any solution to B is also very likely a solution to A. Anybody disagree? If so, I'd suggest that we should either solve A and B at the same time, or not at all. On Jun 8, 2007, at 10:42, Dick Hardt wrote: At IIW we[1] decided we wanted to solve (A) and that (B) would be nice to solve, but we were ok to wait for a future version to resolve, as when we discussed (B), resolving looked much harder then it seemed at first. I'm not certain of where we are now. -- Dick [1] those present when we met about how to solve recycling ... On 8-Jun-07, at 10:35 AM, Recordon, David wrote: I'm not sure if we all think we're trying to solve the same problem. The two problems that have been discussed are: A) Identifier recycling normally in large user-base deployments. i.e. insert big company needs a way to give 'TheBestUsernameEver' to a new user if it has not been used in some period of time. B) Losing control of your own domain name whether that be via someone stealing it or just that you don't want to have to pay for it forever. Have we made a decision as to if we're looking for a solution to solve both of these problems, only A, or only B? --David ___ 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: The CanonicalID Approach
Not really trying to avoid the canonical ID having an OpenID service listed, just figured not listing one would make the example simpler though as you point out you certainly can have one. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Friday, June 08, 2007 1:42 PM Cc: specs@openid.net Subject: Re: The CanonicalID Approach Josh Hoyt wrote: On 6/7/07, Recordon, David [EMAIL PROTECTED] wrote: What I'd like to markup is that my three reassignable identifiers so that they all use my LiveJournal userid URL as the persistent identifier. It should be noted that also marking them as synonyms to each other follows the same sort of process using the Ref/ tag in my various XRDS files. -1 on requiring a whole extra round of discovery for every sign in. If you can come up with a way to verify that (a) the identifier in question points to the canonical ID and (b) the canonical ID has the appropriate information in it without doing twice the discovery, I'd like to hear it. I figure that you could potentially use the same mechanism as delegation to avoid the extra discovery iteration. The problem, as with delegation, is that you need to duplicate the endpoint URL in the source identifier's XRDS document. The canonical identifier must also support OpenID, which I believe is something they were trying to avoid. ___ 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: Do We Agree on the Problem We're Trying to Solve?
I don't see how it requires a centralized registry, if I choose to trust that LiveJournal, or some ugly URL from AOL, etc will never go away then that is my choice. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Friday, June 08, 2007 4:08 PM To: Drummond Reed Cc: specs@openid.net Subject: Re: Do We Agree on the Problem We're Trying to Solve? On 8-Jun-07, at 4:00 PM, Drummond Reed wrote: Drummond Reed wrote: Multiple, redundant identifiers is what canonical ID mapping provides. It doesn't require a master directory; it's as distributed as OpenID itself, i.e., it simply provides a way to map a reassignable URL or XRI to a persistent URL or XRI. Dick Hardt wrote: The persistent URL or XRI *is* a master directory. What do you do when the persistent identifier is compromised, goes out of business ... That is problem B. Canonical IDs do not solve B. I completely agree that B is a hard problem. However Canonical IDs solve B if the identifier authority for the Canonical ID follows business and operational practices intended to solve B. And I think there is a solution that does not require a single, central registry. One of the other issues with the registry is it is challenging to provide directed identities. -- 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
The CanonicalID Approach
So sitting up here in Seattle with Drummond and we're chatting about the Canonical ID approach to the identifier recycling and losing problem. What I describe below is an example which shows four identifiers that I use daily, one of them being persistent and that I know will never be reassigned. http://daveman692.livejournal.com - reassignable http://www.livejournal.com/userinfo.bml?userid=1356357 - persistent http://www.davidrecordon.com - do I want to own it forever? http://openid.aol.com/daveman692 - reassignable What I'd like to markup is that my three reassignable identifiers so that they all use my LiveJournal userid URL as the persistent identifier. It should be noted that also marking them as synonyms to each other follows the same sort of process using the Ref/ tag in my various XRDS files. It should also be noted that the identifier you're using as your persistent identifier must allow you to add references back to your other identifiers. While this certainly is a specialized feature, we envision that OpenID Providers will create a persistence service both guaranteeing the URL will not be reassigned as well as providing means to add additional references. Many of the existing i-brokers already do this by using OpenID to prove you control the references that you're adding. You could also, don't shudder too hard Dick :), use an i-number as your persistent identifier via this method though on the flip-side could also use a fragment if that is the approach someone would like to take. The nice thing is that this method is extremely flexible in terms of what you use as your persistent identifier in different cases. I fully guarantee I haven't done a great job of explaining all of this, but hopefully the main point gets across. --David (and Drummond) http://daveman692.livejournal.com XRDS XRD Service URIhttp://www.livejournal.com/openid/server.bml/URI Typehttp://openid.net/signon/1.0/Type /Service CanonicalIDhttp://www.livejournal.com/userinfo.bml?userid=1356357/Can onicalID /XRD /XRDS http://www.davidrecordon.com XRDS XRD Service URIhttps://pip.verisignlabs.com/openid/server/URI Typehttp://specs.openid.net/auth/2.0/signon/Type LocalIDhttps://recordond.pip.verisignlabs.com/LocalID /Service CanonicalIDhttp://www.livejournal.com/userinfo.bml?userid=1356357/Can onicalID /XRD /XRDS http://openid.aol.com/daveman692 XRDS XRD Service URIhttps://api.screenname.aol.com/auth/openidServer/URI Typehttp://openid.net/signon/1.0/Type /Service CanonicalIDhttp://www.livejournal.com/userinfo.bml?userid=1356357/Can onicalID /XRD /XRDS http://www.livejournal.com/userinfo.bml?userid=1356357 XRDS XRD CanonicalIDhttp://www.livejournal.com/userinfo.bml?userid=1356357/Can onicalID Refhttp://www.davidrecordon.com/Ref Refhttp://daveman692.livejournal.com/Ref Refhttp://openid.aol.com/daveman692/Ref /XRD /XRDS ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
The WordPress User Problem (WAS: RE: Specifying identifier recycling)
I think the largest concern I have with fragments, or really any pair-wise shared secret which can't be renegotiated, is that while it solves issues for the large service providers it actually inhibits OpenID within the grassroots community. Imagine if I install WordPress (or insert other app here) on https://davidrecordon.com and check the Use fragments to protect my OpenID box. A few months later I decide to remove WordPress, or an upgrade blows away my OpenID extension data, or I'm using an extension which stores the fragments in /tmp/ and they get blown away. I now no longer have access to my accounts on all the relying parties I've visited. Now what do I do? We can't count on each RP implementing an account recovery mechanism; remember OpenID outsources account management so you can focus on building you application. I can't call up my service provider and ask them to fix it, since well I was using my own provider. I could try to call up my webhost and see if they can restore from a backup, but I'd guess by the time I realize what that check box in my WordPress extension settings did there may not even be backups anymore. In the end, I'd be extremely frustrated that OpenID didn't work for me and I'd write a really obnoxious blog post about how much OpenID sucks. So while we solve one aspect of the recycling problem, we end up creating a larger problem from the opposite side of the equation. I'm certainly not arguing that we shouldn't solve this problem, nor that participation from large providers isn't vital, but would hate to see us create a problem for all of the people out there that have really helped gain OpenID traction. I don't want to say that I have the answers here, since I don't think I do. I do however see the following possible solutions: 1) The core specification only talks about fragments in relation to Relying Parties, to the extent that they should be stripped from display though used as a unique key. We do however need to address how a RP should handle display and account management differences when a fragment changes. I'm guessing it is unreasonable to expect every instance of https://davidrecordon.com to be replaced with https://davidrecordon.com/#231hwqai21jb when the fragment changes (not to mention that the fragment *must* remain private between the OP and RP to be effective). An extension is then written describing fragment usage from the OP perspective with huge warnings about how it should only be used by large service providers who know what they're doing. 2) We use a centralized canonical id approach like i-numbers. Basically somebody issues unique and never reassigned ids. 3) We use a distributed canonical id approach. Providers issue an ugly non-reassignable URL which points at the pretty one and vice-versa. Thus https://davidrecordon.com says its canonical is https://12jbd9210.pip.verisignlabs.com which in turn says it is https://davidrecordon.com. We could even kill two birds with one stone and use link rel='me' / to do this and setup an easy way to create identifier equality. 4) We use public/private key pairs, though this has the traditional private key revocation issues. I think my preference is #3, though I'm sure it has its own issues. --David -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Sunday, June 03, 2007 6:35 PM To: Recordon, David Cc: Johannes Ernst; OpenID specs list Subject: Re: Specifying identifier recycling On 3-Jun-07, at 1:46 AM, Recordon, David wrote: I thought at IIW we agreed that if we could come to quick consensus on a way to resolve the problem it would be a part of 2.0, otherwise it would not... Agreed, nobody wants to delay 2.0 indefinitely if we can't agree on how to solve this issue. But the issue was deemed important enough to be one of the only two on the 2.0 agenda. As concerns with the fragment proposal have been raised, which had the most agreement at IIW, it seems we no longer have consensus. I haven't seen many actually; checking this thread for what can count as concerns reveals only: a) Josh's initial email b) Johannes' +1 to not adopting a solution that doesn't actually work c) David acknowledging the concerns This doesn't seem to me to carry enough weight to veto the fragment proposal, especially when a) has been / can still be addressed, and the fragment proposal made sense to a dozen people at that meeting. As seen in this thread, there are a wide variety of opinions as to how to resolve this concern. I thus think merely picking one for the sake of putting something into 2.0 would be misguided. True, there have been a few (I definitely wouldn't call it a wide variety) possible solutions mentioned, but none very well defined, and none had the support of 10+ people like the fragment did. I have argued that it will have to be core (whether 2.0 or 3.0). I guess we should ask ourselves then if we really want this addressed in 2.0
RE: Auth 2.0 Extensions: Namespace Prefixes
Since it seems no one has replied yet, I'd agree that this would make implementations easier. Iterating via a regular expression seems ugly and hard to do (well except in Perl). :-\ --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Monday, April 30, 2007 12:48 PM To: specs@openid.net Subject: Auth 2.0 Extensions: Namespace Prefixes As currently defined, an extension has a global namespace URI as well as a request-local alias/prefix. For an extension with the namespace http://example.com/blah that has a field foo, the following fields are to be sent: openid.ns.blah=http://example.com/blah openid.blah.foo=bar It seems to me that the only way to discover the extension namespaces used in a particular message is to iterate over all keys looking for openid.ns.(\w+) and then see if the value matches. This seems ugly since usually webapps deal with such arguments as a dictionary structure, and use dictionary dicipline while interrogating the values. If we added an extra field: openid.extensions=blah,sreg,ax then the extensions used in a message would be accessible by splitting that field on its commas and then accessing openid.ns.whatever for each one. It's still not ideal, of course; it'd be better if the full namespace URI were included in the key part of a (key,value) pair, but many frameworks[1] can't deal with wacky punctuation characters in the key. [1] I'm looking at you, PHP. ___ 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: The WordPress User Problem (WAS: RE: Specifying identifier recycling)
At that point I'd be concerned as to solving the big OP issue while not solving the lost domain issue when some of the proposals could possible solve both. This largely focuses around using an XRI-style canonical id, whether that be an i-number or just another ugly URL which points back at the pretty one. I know I need to write this up more... --David -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 05, 2007 3:18 PM To: Recordon, David Cc: Josh Hoyt; Johannes Ernst; OpenID specs list Subject: Re: The WordPress User Problem (WAS: RE: Specifying identifier recycling) On 5-Jun-07, at 11:58 AM, Josh Hoyt wrote: The relying parties SHOULD make the fragment available to software agents, at least, so that it's possible to compare identifiers across sites. If the fragment is never available, then there is confusion about which user of an identifier is responsible for content that has been posted. One use case where software agents having access to the fragment is particularly important is if the identifier is used for access control, and the access control list is retrieved from off-site (e.g. from a social networking site). The implementation that seems most sane is for places that display the identifier for human reading look like: a href=http://josh.example.com/#this-is-intended-for-machine- consumption http://josh.example.com//a so that the software agent would see the fragment, but the user wouldn't have to. On 5-Jun-07, at 2:55 PM, Recordon, David wrote: I thought the fragment was to be secret so that for the case of using a personal domain you don't have to own joshhoyt.com forever. Rather as long as your fragments are secret, someone else can buy joshhoyt.com and not be you. If this is no longer a requirement then it certainly changes the game, though also doesn't solve one of the other aspects of identifier recycling. I thought so too, but I believe Josh is right - the lost domain cell with an X in it (for URL + public fragment) supports Josh's statement: http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling So if we're not dealing with this use case, it becomes actually simpler to address just the identifier recycling for big OPs, where loosing the domain is not an issue. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Specifying identifier recycling
I thought at IIW we agreed that if we could come to quick consensus on a way to resolve the problem it would be a part of 2.0, otherwise it would not... As concerns with the fragment proposal have been raised, which had the most agreement at IIW, it seems we no longer have consensus. As seen in this thread, there are a wide variety of opinions as to how to resolve this concern. I thus think merely picking one for the sake of putting something into 2.0 would be misguided. --David -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Saturday, June 02, 2007 10:12 PM To: Recordon, David Cc: Johannes Ernst; OpenID specs list Subject: Re: Specifying identifier recycling On 2-Jun-07, at 5:14 PM, Recordon, David wrote: I'd like to see this written as an extension so that if the first approach doesn't work, the Auth spec itself doesn't have to be reverted. Rather we can finish 2.0 and try implementing different approaches before deciding on the final way to solve this problem. I thought we had agreed at IIW (for good reason) to address this in 2.0. Other than the actual solution not being 100% clear, has anything changed? Arguments for not putting it into an extension: - users of provider's X who employs 'identifier recycling extension' would not be able to log into RP Y who doesn't understand the extension - it's likely that whatever solution we come up with affects the discovery / verification processes, in which case it couldn't be pushed to an extension (we're trying to patch something about the _identifier_ itself, which is the center of each openid transaction). Also, I believe the fragment approach can actually work, as detailed here: http://openid.net/pipermail/specs/2007-May/001767.html I haven't seen any replies to this, so would appreciate if others would go through the proposed changes and see if they all makes sense of I've overlooked something. Thanks, Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Specifying identifier recycling
Overall, I'm not sure we are ready in this community to pick one alternative over another as the standards. I have my views, (many) others have (many) others -- and I don't think that any of this has to be in an Authentication 1.x (x1) or 2.0 spec, whatever it will be. This seems like a clean add-on. I also agree with Johannes here. I'd like to see this written as an extension so that if the first approach doesn't work, the Auth spec itself doesn't have to be reverted. Rather we can finish 2.0 and try implementing different approaches before deciding on the final way to solve this problem. SREG shows how 1.1 can be extended, 2.0 clarifies this mechanism and makes it more robust, let's take advantage of it especially given that not all providers require this feature (whether via fragments or public keys). --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Wednesday, May 30, 2007 10:30 PM To: OpenID specs list Subject: Re: Specifying identifier recycling If we cannot assume that nobody manages to obtain a secret they should not have gotten in the first place, then OpenID as it stands is rather useless as we cannot trust its authentication scheme. Note that the surface through which the D-H shared secret can escape is about twice as large as the surface through which a private key can escape -- because an RP does not have access to the private key. In other words, if I was an attacker, I'd go after a lot of things first before I'd try to obtain a private key. Note also that public keys would make rather good i-numbers -- for those who would like to, they can ignore that they are public keys and do i-number-based verification only, because they are simply numbers. For those who don't care about i-numbers, they use their public key aspects. Win-win, perhaps? There is also the case -- which Stefan Brands would undoubtedly bring up if he was on this list -- that the IdP may be hostile, or may become hostile. (think of, say, a large OpenID provider going out of business, and being bought out by spammer.com -- or just the domain name whose registration lapsed) A scheme that is public key based is inherently more resilient towards this than one that is not. You certainly don't want to trust spammer.com to honor whatever conventions the previous owner of the domain put in place to disambiguate their users. -- Overall, I'm not sure we are ready in this community to pick one alternative over another as the standards. I have my views, (many) others have (many) others -- and I don't think that any of this has to be in an Authentication 1.x (x1) or 2.0 spec, whatever it will be. This seems like a clean add-on. On May 30, 2007, at 22:01, Drummond Reed wrote: Johannes: What about the point Dick posted earlier in this thread, that the problem with using a public key is if the private key gets compromised? Persistent identifiers need to persist independent of any attribute changing or being revoked. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Wednesday, May 30, 2007 9:54 PM To: OpenID specs list Subject: Re: Specifying identifier recycling On May 30, 2007, at 21:02, Johnny Bufu wrote: ...The bottom line is that it can't be done easily - a mechanism similar to XRI's canonical ID verification would have to be employed, to confirm that the i- number actually 'belongs' to the URL on which discovery was initiated. (Otherwise anyone could put any i-number in their URL- based XRDS files.) Public keys ... public keys ... with the added benefit that no centralized or trusted verification service needs to be employed whatsoever ... Johannes Ernst NetMesh 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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Specifying identifier recycling
Just for reference, this draft spec takes a look at key discovery for OpenID URLs. http://openid.net/specs/openid-service-key-discovery-1_0-01.html --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Friday, June 01, 2007 1:40 PM To: Nat Sakimura Cc: 'OpenID specs list' Subject: Re: Specifying identifier recycling On May 31, 2007, at 18:41, Nat Sakimura wrote: Public key idea is somewhat attractive to me, but there are some issues that comes up in my mind as well. Bring them on ;-) 1) Storing many users' private key on the server in decryptable format is not very safe. In your proposal, it looks like that OP is going to hold the private key for each user in decryptable format. Considering that most large scale privacy leakage happens at the server side, I have got a feeling that such thing like private key in a shared location. How would this be less safe than storing many shared secrets (per OpenID Auth) in decryptable format, or clear-text (more likely) on the server? Note that these private keys would not be general-purpose private keys, but only for the specific purpose we are discussing here. Also, I suspect that the use of these keys would be fairly infrequent compared to other operations, so conceivably one could add additional safeguards of various kinds if that was needed. 2) It may mean a high cost operation for OPs. If we do this, it makes OP operation very high cost because to make the service safe, it would require a lot of measures. (NRI is providing similar kind of service but it indeed is very high cost operation.) Nice thing about i-number is that it has no value like public key except for its resolvability. Even if it leaks, that's kind of ok so operational risk is low. This comparison does not work very well for me. However: I don't know the details of how to avoid impersonation via i-numbers (in case of key pairs, it would be private key leaks and is reused by attacker -- what would be the equivalent for i-numbers?), but I suspect there are some measures that prevent attackers from impersonation by using somebody else's i-number? If so, aren't they similarly susceptible to attack? Actually, these private key pain may be eased by IBE (Identity Based Encryption) but I need some more time to contemplate on it. I had somebody else mention this to me -- I wonder whether anybody could put together an actual proposal. 3) Since OPs has an access to the users' private key, they may recycle them as well. IMHO, recycling is operational problem as well as a technical one. i-number from a certified i-broker is somewhat trustable on the account of no recycling because of this operational restriction. Could there be operational restriction similart to that for general OPs as well? There could, and -- I suspect -- in the longer term there probably will, but the whole point about a decentralized system like OpenID is to keep the playing field level without a central entity in the middle for the maximum length of time and scope possible. In any case, I think we should use the approach to use (decentralized) technology to the maximum extent possible, and only add operational requirements when unavoidable. (And I know that many people on this list would scream bloody murder if anybody seriously proposed such a centralized requirement for OpenID usage ...) Personally I would feel we didn't think hard enough on this particular problem if the solution to this problem required us to use centralization of some kind. =nat -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Thursday, May 31, 2007 2:30 PM To: OpenID specs list Subject: Re: Specifying identifier recycling If we cannot assume that nobody manages to obtain a secret they should not have gotten in the first place, then OpenID as it stands is rather useless as we cannot trust its authentication scheme. Note that the surface through which the D-H shared secret can escape is about twice as large as the surface through which a private key can escape -- because an RP does not have access to the private key. In other words, if I was an attacker, I'd go after a lot of things first before I'd try to obtain a private key. Note also that public keys would make rather good i-numbers -- for those who would like to, they can ignore that they are public keys and do i-number-based verification only, because they are simply numbers. For those who don't care about i-numbers, they use their public key aspects. Win-win, perhaps? There is also the case -- which Stefan Brands would undoubtedly bring up if he was on this list -- that the IdP may be hostile, or may become hostile. (think of, say, a large OpenID provider going out of business, and being bought out by spammer.com -- or just the
RE: Review of Yadis section in XRI Resolution 2.0 WD11
Hi Drummond, I'd recommend adding a section which pulls together the HEAD and GET methods and describes how'd they be used in conjunction. Also explicitly pointing out that a URL hosting a XRDS document only is required to implement one or more of the discovery mechanisms whereas a service requesting XRDS documents must implement all of the different methods. Thanks, --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drummond Reed Sent: Wednesday, May 30, 2007 10:45 PM To: 'OpenID specs list' Subject: Review of Yadis section in XRI Resolution 2.0 WD11 As discussed at IIW, the OASIS XRI TC is now moving swiftly to close and vote on the XRI Resolution 2.0 spec (which has been at the Working Draft 10 stage during the entire evolution of OpenID Authentication 2.0) so it can be referenced by OpenID Authentication 2.0 when it goes final. To that end, the first editor's draft of Working Draft 11 has been posted [1]. It's not quite content complete (all major changes have been incorporated; we're now working on the smaller stuff), so we're not asking folks to review the whole thing yet (many OpenID folks think it's too long anyway ;-). However it would be great to get feedback on the new section 8 that incorporates the Yadis protocol. Per discussions with the OpenID editors last fall, the XRI TC is including this in the XRI Resolution spec so everything about XRDS documents and their discovery is referenceable in an open public OASIS spec, even if only URLs and no XRIs are involved. To make this new section easy to review, we've put it on the XRI TC wiki at: http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris It's pretty short and sweet, mostly because XRDS documents and their context and usage are defined elsewhere in the spec. So this section just defines the URL-based discovery protocol, which is the meat of the Yadis 1.0 spec. The wording has been restructured slightly to fit the OASIS spec format, however the only normative change was to make the recommendation to include the application/xrds+xml Accept header in the HEAD or GET request a SHOULD instead of a MAY. The XRI TC felt this was justified to encourage efficiency -- feel free to push back if you think that's the wrong call. Since only XRI TC members can write to the wiki (due to OASIS IPR rules), please post any feedback here on the specs list and we'll reflect it on the wiki page as quickly as we can (I myself will be offline in meetings tomorrow but back online tomorrow night). Thanks, =Drummond [1] http://www.oasis-open.org/committees/download.php/24096/xri-resolution-v 2.0- wd-11-ed-01.doc ___ 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: Realm spoofing spec patch
Hey Josh, Thanks for writing this up! I'm a bit confused by the number of SHOULDs in this patch. +Relying Parties SHOULD use the Yadis protocol to publish their +valid return_to URLs. The relying party MAY publish this +information at any URL, and SHOULD publish it under the realm +so that providers can verify return_to URLs. +OpenID providers SHOULD verify that the return_to URL +specified in the request is an OpenID relying party +endpoint. +If verification is attempted and fails, the provider +SHOULD NOT send a positive assertion to that return_to +URL. It seems that this methodology only works if either: 1) Every site (RP or proxy) publishes their return_to endpoints or that they don't have any. 2) An OP refuses to let the user login to a RP which doesn't publish their return_to endpoint. I'm unconvinced that either of those situations will actually become prevalent and thus worried about the effectiveness of this methodology. Using the same example from IIW, I am logging into http://evilrp.com/return_to which is proxying itself through http://www.google.com/translate/. If my OP were to prompt me, We're unable to verify the site (http://www.google.com/translate/?http://evilrp.com/return_to) you're logging into, you should use caution when proceeding I'm unsure how many users would actually not proceed, or rather see google.com and decide it is alright. I guess since we're unable to fully resolve this issue from a technical perspective, and no I don't have a better technical solution, I'm wondering if this should actually be an extension to the core protocol versus seeming like a resolution to the problem when it really doesn't completely solve it. In some senses I see this as a larger problem around trust of Relying Parties. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Thursday, May 24, 2007 4:19 PM To: OpenID specs list Subject: Realm spoofing spec patch Hello, I've added a section to the specification[1] about performing verification on the realm to avoid realm spoofing. In short, realm spoofing is the problem of exploiting a bug on a site that a user would trust to trick them into sending their information to a site that they would not trust. This is very similar to many phishing attacks. The difference between this type of attack and a standard phishing attack is that the user will (usually) only see the realm, and the realm may actually be trusted, so even an educated user who's paying attention may be vulnerable. There are also (minor) changes to the section on discovering relying parties[2]. The fix that is described is for the relying party to provide a whitelist of URL patterns that should be usable as return_to URLs. Relying parties should be as restrictive as possible when specifying return_to URLs. This is the fix that was discussed at the Internet Identity Workshop, by all of the spec editors and several prominent members of the OpenID community. Please review the additions. If you'd like to see the specific changes, you can look at the diffs in revision control[3]. Josh 1. http://j3h.janrain.com/openid-specs-rendered/openid-authentication_svn- 327.html#return_to_verification 2. http://j3h.janrain.com/openid-specs-rendered/openid-authentication_svn- 327.html#return_to_verification 3. http://openid.net/svn/listing.php?repname=specificationspath=rev=326; sc=1 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Wiki Login Fixed
Thanks to Jonathan from JanRain, you can now login to the wiki again! --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: axschema.org instead of openid.net
Sounds good! --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Friday, April 20, 2007 12:46 PM To: OpenID specs list Subject: axschema.org instead of openid.net Thanks everyone for feedback on using schema.openid.net. Here are my conclusions: 1) A number of people would like to be using a web oriented schema right away and don't want to wait for other groups to create the schema. 2) A number of people are allergic to the openid.net domain being used for things that are not openid.net protocol specific. Sxip has acquired axschema.org (Attribute eXchange schema :-) and we will host the site and a mail list as a service to the community and operate it per http://openid.net/specs/openid-attribute- types-1_0-02.html If I don't hear from anyone that they don't like this idea, then we will set this up next week. -- 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: PROPOSAL schema.openid.net for AX (and other extensions)
Hey Brian. Just to clarify, I don't think there is disagreement that this should be discussed here. Rather the question is if discussion should be around creating a new schema on openid.net or rather looking at using an exisiting one such as ldap.com that Mark posted about? Ie, discussion location aside, do you believe the OpenID project should be creating a new schema of its own? --David -Original Message- From: Brian Hernacki [mailto:[EMAIL PROTECTED] Sent: Monday, April 09, 2007 09:48 AM Pacific Standard Time To: OpenID specs list Subject:Re: PROPOSAL schema.openid.net for AX (and other extensions) On 4/6/07 6:07 PM, Dick Hardt [EMAIL PROTECTED] wrote: If anyone implementing would like to do something different, then I'd welcome additional discussion, otherwise I think we should be able to move forward with the proposal. For what it's worth, as an implementer... I think it makes sense to come to agreement within the OpenID community and get something working first. While I appreciate the issues involved with having multiple protocols and attribute definitions, I worry that if this becomes coupled to other efforts it would cause delays. Better to at least come to that table with a sound version of what we think works. Given that, discussing it here (openid.net) seems natural. --brian ___ 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: PROPOSAL schema.openid.net for AX (and other extensions)
Yes, I agree an upgrade path from SREG is needed. We could however do something as simple as http://openid.net/specs/openid-simple-registration-extension-1_0.html#ni ckname for the existing SREG fields. For new fields, is there a reason we can't use the ldap.com URLs Mark posted as a starting point? I know Dick said they didn't cover all the needed attributes, but would it be good enough to start with and then expand from there possibly on schema.openid.net? Dick, do you have a list of attributes you see as needed for the first implementations of AX (I couldn't find one in the current AX specs though I fully admit I may be looking in the wrong place)? --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Walker Sent: Monday, April 09, 2007 1:10 PM To: Martin Atkins Cc: OpenID specs list Subject: Re: PROPOSAL schema.openid.net for AX (and other extensions) On 4/9/07 3:55 PM, Martin Atkins wrote: James Walker wrote: As an implementor - there would be extremely positive benefits from having a base set of attributes defined and available @ schema.openid.net . I agree that the people most interested right now are the OpenID community implementors and it makes sense (to me) for openid.net to offer something - even just as a 'getting started point'. [snip] What we need now (from my point of view) is a base set that we can work against to build momentum behind AX (building on the momentum already behind OpenID). If our goal is to not reinvent the wheel, then let's just identify some AX mappings for the existing SREG fields, thus killing two birds with one stone: people migrating from SREG get some fields that offer one-to-one mappings, and these fields can be defined just by referencing the existing SREG specification so we avoid having to define anything. SREG seems to be working well in the common case, so it seems like a reasonable place to start. I agree it's an excellent place to start - upgrade path + as you point out it's working well in several cases today. -- James Walker :: http://walkah.net/ :: xmpp:[EMAIL PROTECTED] ___ 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: PROPOSAL schema.openid.net for AX (and other extensions)
Is there a list anywhere? I didn't find one in the documents and I think this list would benefit everyone in the conversation. I'm just curious as to the fields you're expecting an OP to implement. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Monday, April 09, 2007 07:12 PM Pacific Standard Time To: Recordon, David Cc: James Walker; Martin Atkins; Mark Wahl; OpenID specs list Subject:Re: PROPOSAL schema.openid.net for AX (and other extensions) On 9-Apr-07, at 5:24 PM, Recordon, David wrote: For new fields, is there a reason we can't use the ldap.com URLs Mark posted as a starting point? I know Dick said they didn't cover all the needed attributes, but would it be good enough to start with and then expand from there possibly on schema.openid.net? Dick, do you have a list of attributes you see as needed for the first implementations of AX (I couldn't find one in the current AX specs though I fully admit I may be looking in the wrong place)? There are many, many attributes that we are using in AX that are not in LDAP, or don't have the granularity. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: SREG namespace URI rollback
I'm fine with keeping it 1.0 as Josh proposed. --David -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Saturday, April 07, 2007 09:38 PM Pacific Standard Time To: Recordon, David Cc: Josh Hoyt; OpenID specs list Subject:Re: SREG namespace URI rollback On 2-Apr-07, at 6:06 PM, Recordon, David wrote: Sure, though I think there has also been a desire to do a bit of an Are we in agreement then (about 1.0 and 1.1 sharing the same type URI)? I went ahead and implemented SREG in openid4java, and exposed it in such a way that the users won't have to know about all these v1.0 / 1.1 details. But in order for that to work and my implementation to be compliant, the type URI of SREG 1.1 needs to change as proposed by Josh in the next (final?) draft. Thanks, Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: PROPOSAL schema.openid.net for AX (and other extensions)
I think it is great that there is new and innovative work in what you've been doing. I would also think that it would benefit the entire user-centric (and even non-user-centric) community to take advantage of this work regardless of the technology. By having it rooted on openid.net, I think there will be aversion to doing so and other communities will rather jump to the conclusion that the OpenID community is yet again reinventing the wheel by defining common core attributes. This is what I want to avoid. By doing this in a neutral location, not tied to a specific identity technology, it removes this concern as well as does more good for the entire ecosystem. If the ID Schemas project is not the right place to do it, then I see no reason not to create one; I would be happy to front the cost of a domain name if needed. I'd also think this would be something worth discussing at IIW when the entire community comes together. I would really like to see this be something that can be used by OpenID, CardSpace, Higgins, SAML, etc. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 1:07 PM To: Recordon, David Cc: OpenID specs list; Paul Trevithick; Mark Wahl Subject: Re: PROPOSAL schema.openid.net for AX (and other extensions) If there was something out there already, I would propose we used it. There is not. Just like the SAML crowd has accused the OpenID crowd of reinventing an identity protocol (AKA reinventing the wheel) -- the AX proposal has some unique concepts that people like Paul and Mark think are quite innovative. Other schemas don't support them. I have cc'ed Paul and Mark in case they can point to some new work that we can take advantage of today. Other responses inserted: On 6-Apr-07, at 11:49 AM, Recordon, David wrote: As I've stated in the past, I have no problem with using schema.openid.net to define attributes such as the authoritative URI for an OpenID URL, i-name, etc. I do have a problem with using this namespace to define an attribute such as a First Name. I do not feel that this community should be dealing with all of the issues such as First Name vs. Given Name, as that is not where the expertise is, let alone it has been done in the past. I also strongly believe that due to the number of other definitions of these attributes, either we as a community should decide to use one of them or work with a project such as ID Schemas to create a set of URIs not tied to the OpenID project that solves both our needs and the needs of others. I do not particularly care where this work would happen and as I've said in the past, I'd be fine with someone just buying a domain to do the work to preserve the speed for getting this bootstrapped while not tying it to OpenID. If really don't care, then you should not care if it is happening in OpenID then. First Name: - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname This URL could be used. To date they have not made these self describing. Who knows what this is? The AX proposal is to make the URLs describing. This makes it easier for programmers to know what it is they are working with. - http://xmlns.com/foaf/0.1/firstName - http://xmlns.com/foaf/0.1/givenname Both of these are elements in a larger XML document. This is not the model of AX. - http://en.wikipedia.org/wiki/First_name While intriguing to have wikiality define terms, this is not practical since the definition needs to be static or code will break I'm sure if Paul Trevithick or Mark Whal join this conversation they'd be able to highlight even more URI definitions of a First Name than I was in a cursory search. This also isn't including all of the work done for things such as LDAP, vCard, or others listed at http://idschemas.idcommons.net/moin.cgi/List_Of_Schemas in defining what these schema attributes are and mean. Most other work has created closed schemas. The AX proposal is an open schema where anyone can define a new attribute and each one is self describing. If we want to create URLs for attributes from an existing schema (such as LDAP or vCard) since easy URLs do not currently exist, then that is one thing. Creating an entirely new definition of commonly used attributes IMHO is unacceptable. People keep doing it for a variety of reasons. People keep inventing new programming languages. We should be reusing anything that we can, not inventing something new especially given the complexity of this particular task. The task has largely been done. Still need to finalize the meta-data file format. I'm not sure what more I can do to urge this community to not reinvent the wheel in this area. See comment at top. AX does not need a wheel. AX needs a wing. Wings don't exist right now. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman
RE: PROPOSAL schema.openid.net for AX (and other extensions)
You also could go buy idschemas.org and start there, to be migrated later if need be. I don't really care who owns the domain since the wider community will hold the owner to do the right thing, though I'd imagine donating it to Identity Commons to hold would be an easy thing to do. Yes, VeriSign is activly developing OpenID 2.0 code in Java (http://code.google.com/p/joid/) and evaluating if/when we'll be implementing Attribute Exchange alongside Simple Registration. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 6:07 PM To: Recordon, David Cc: OpenID specs list; Paul Trevithick; Mark Wahl Subject: Re: PROPOSAL schema.openid.net for AX (and other extensions) The work is not rooted in openid.net. We are starting there. We can easily point those definitions somewhere else later, but we need somewhere to start. Given that the community that cares today is in OpenID, and the domain the community has is openid.net, it would make sense to use that domain. A different domain is going to have the same issues of control. I would expect that other members of the community would have concerns if it was rooted at say sxip.org. Happy to have further discussions at IIW, but don't see why the work here should wait until then. Other communities may or may not want to take advantage of what we are doing, and it will be easier for them to understand what we have if we have working code then just more talk about it. To take a step back, the people to decide this should be the people that are doing implementations. Would you clarify David if *you* are implementing, or just sharing your opinion? If anyone implementing would like to do something different, then I'd welcome additional discussion, otherwise I think we should be able to move forward with the proposal. -- Dick On 6-Apr-07, at 2:03 PM, Recordon, David wrote: I think it is great that there is new and innovative work in what you've been doing. I would also think that it would benefit the entire user-centric (and even non-user-centric) community to take advantage of this work regardless of the technology. By having it rooted on openid.net, I think there will be aversion to doing so and other communities will rather jump to the conclusion that the OpenID community is yet again reinventing the wheel by defining common core attributes. This is what I want to avoid. By doing this in a neutral location, not tied to a specific identity technology, it removes this concern as well as does more good for the entire ecosystem. If the ID Schemas project is not the right place to do it, then I see no reason not to create one; I would be happy to front the cost of a domain name if needed. I'd also think this would be something worth discussing at IIW when the entire community comes together. I would really like to see this be something that can be used by OpenID, CardSpace, Higgins, SAML, etc. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 1:07 PM To: Recordon, David Cc: OpenID specs list; Paul Trevithick; Mark Wahl Subject: Re: PROPOSAL schema.openid.net for AX (and other extensions) If there was something out there already, I would propose we used it. There is not. Just like the SAML crowd has accused the OpenID crowd of reinventing an identity protocol (AKA reinventing the wheel) -- the AX proposal has some unique concepts that people like Paul and Mark think are quite innovative. Other schemas don't support them. I have cc'ed Paul and Mark in case they can point to some new work that we can take advantage of today. Other responses inserted: On 6-Apr-07, at 11:49 AM, Recordon, David wrote: As I've stated in the past, I have no problem with using schema.openid.net to define attributes such as the authoritative URI for an OpenID URL, i-name, etc. I do have a problem with using this namespace to define an attribute such as a First Name. I do not feel that this community should be dealing with all of the issues such as First Name vs. Given Name, as that is not where the expertise is, let alone it has been done in the past. I also strongly believe that due to the number of other definitions of these attributes, either we as a community should decide to use one of them or work with a project such as ID Schemas to create a set of URIs not tied to the OpenID project that solves both our needs and the needs of others. I do not particularly care where this work would happen and as I've said in the past, I'd be fine with someone just buying a domain to do the work to preserve the speed for getting this bootstrapped while not tying it to OpenID. If really don't care, then you should not care if it is happening in OpenID then. First Name: - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname This URL could be used. To date they have
RE: Moving AX Forward (WAS RE: SREG namespace URI rollback)
I guess I don't see why blaming the ID Schemas project for not much happening is a good excuse for not doing it there. People who care will either have to drive this work within the OpenID project or the ID Schemas project; I fail to see how the effort required in each differs greatly. In some senses, I think if people gather as part of the ID Schemas project and try to move this work forward, it will actually be more successful than trying to do it here. Nothing done by OpenID in the past has intrinsically been easy which is why I continue to think that something being hard is not a valid reason to not do the right technical/social thing. I know that these two communities can work together, but the onus is on the OpenID AX side to make this conversation successful and drive progress. Cc'ing their list as well. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Thursday, April 05, 2007 8:00 AM To: Drummond Reed Cc: Recordon, David; 'Johnny Bufu'; 'OpenID specs list' Subject: Re: Moving AX Forward (WAS RE: SREG namespace URI rollback) Doing the work in the ID Schemas project was a good idea 3 months ago and 6 months ago. So far not much has happened there. I agree that having several groups do the same thing is undesirable, but we do need to get moving. We need URIs for moving attributes today. We can wait for the metadata [1] to get defined, and the members of the ID Schema group are the right people for that.[2] While it is desirable that there is only one definition of an attribute, and some people may define the same attribute through lack of knowledge of each other. The attribute meta data model proposed[1] allows for one definition to reference another definition to consolidate attribute definitions. Additionally, getting everyone to agree on the syntax will be hard. The model allows different people to define attributes in different ways. The market will decide then what works best through use. btw: Currently there is no consistent, extensible, self describing attribute schema system out there that I know of, or anyone in the ID Schema Working group knows of. We can start to define attributes in the openid.net namespace and then reference more authorative URIs when they exist. This would let the OpenID community define the immediately required attributes for people to implement and deploy AX, which will likely increase awareness [1] http://openid.net/specs/identity-attribute-metadata-1_0-01.html [2] Of course we have all the issues of IPR etc. at the ID Schema working group since it would be unclear what organization would be managing that spec. Over here in the OpenID community we are working to resolve that, so perhaps the ID Schema people could participate in a list hosted at openid.net? -- Dick On 4-Apr-07, at 10:27 PM, Drummond Reed wrote: +1 to defining attribute identifier URIs/XRIs in the Identity Commons ID Schemas project. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Wednesday, April 04, 2007 1:16 PM To: Johnny Bufu Cc: OpenID specs list Subject: RE: Moving AX Forward (WAS RE: SREG namespace URI rollback) Johnny, I see a lot of, at least my initial confusion, coming from there being multiple documents. This is why I urge merging the transport and metadata since the reality is they currently are only being used with each other. As the metadata document doesn't actually define a new format, rather references existing formats, I am unsure why it cannot just be a section in the transport document. It is understood that you must use the metadata format for the schema URLs in the transport, so the two documents really are coupled to begin with. I agree that you need to bootstrap a set of attributes for people using AX. As I have done so in the past, I'd encourage this work happen within the ID Schemas project (http://idschemas.idcommons.net/) versus defining First Name yet again for openid.net. I have no problem with the spec listing a set of schema URLs, I just strongly feel that anything non-OpenID specific should be hosted and defined elsewhere since so many people have already done it. I do understand the need for the schema URL hosting the metadata document, which is why I am advocating this work be done as part of the ID Schemas project to provide this flexibility. --David -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 04, 2007 12:39 PM To: Recordon, David Cc: Dick Hardt; OpenID specs list Subject: Re: Moving AX Forward (WAS RE: SREG namespace URI rollback) On 4-Apr-07, at 12:18 PM, Recordon, David wrote: One thing that I do think would be worthwhile in smoothing more of this SREG/AX confusion would be adding SREG support to Sxip's OpenID libraries. This is on the todo list, and judging by the interest showed by some contributors could
RE: Moving AX Forward (WAS RE: SREG namespace URI rollback)
Actually it is describing a document format, and it could easily be used by other groups as evidenced by references from people in the ID Schemas group. I agree that it could be, but is anyone? I love shooting beyond the 80% to get the remaining 20%, but if that is just a pipe dream then I have a hard time seeing why the documents need to be separate and thus more complex. If however this format was defined within the ID Schemas project, then that would be an easy argument as to why they should be separate. We defined a set of attributes 6 months ago under schema.openid.net. So Dick, this is part of my problem with AX. Sxip has defined a set of attributes and never gained consensus on this list that that is the right thing to do. See my other message a few minutes ago as to the rest of my thoughts. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Thursday, April 05, 2007 8:27 AM To: Recordon, David Cc: Johnny Bufu; OpenID specs list Subject: Re: Moving AX Forward (WAS RE: SREG namespace URI rollback) On 4-Apr-07, at 1:16 PM, Recordon, David wrote: Johnny, I see a lot of, at least my initial confusion, coming from there being multiple documents. This is why I urge merging the transport and metadata since the reality is they currently are only being used with each other. As the metadata document doesn't actually define a new format, rather references existing formats, I am unsure why it cannot just be a section in the transport document. It is understood that you must use the metadata format for the schema URLs in the transport, so the two documents really are coupled to begin with. Actually it is describing a document format, and it could easily be used by other groups as evidenced by references from people in the ID Schemas group. I agree that you need to bootstrap a set of attributes for people using AX. As I have done so in the past, I'd encourage this work happen within the ID Schemas project (http://idschemas.idcommons.net/) versus defining First Name yet again for openid.net. I have no problem with the spec listing a set of schema URLs, I just strongly feel that anything non-OpenID specific should be hosted and defined elsewhere since so many people have already done it. I do understand the need for the schema URL hosting the metadata document, which is why I am advocating this work be done as part of the ID Schemas project to provide this flexibility. see my response to Drummond ... We defined a set of attributes 6 months ago under schema.openid.net. I think we have let other groups have time to do something, I'd like to get on with building and deploying stuff. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: SREG namespace URI rollback
In some sense both, maybe it is just how the documents seem to be laid out, it just doesn't seem as dead simple as SREG. Maybe it is just reworking the layout of http://openid.net/specs/openid-attribute-exchange-1_0-04.html and removing the document about policy versus technology http://openid.net/specs/openid-attribute-types-1_0-02.html. Can we also separate out all of the SAML stuff, as far as I can tell it isn't up on the specs page but I think the discussions around these four different documents without clearly being able to tell when people are talking about what has been detrimental to the entire process. I think I'd propose the following: - Remove http://openid.net/specs/openid-attribute-types-1_0-02.html (I do not believe OpenID should define its own schema elements for things like First Name which are not specific to OpenID, defining a URL for an OpenID enabled URL for example I think would be fine on OpenID.net) - Merge http://openid.net/specs/identity-attribute-metadata-1_0-01.html into http://openid.net/specs/openid-attribute-exchange-1_0-04.html. - Cleanup the newly merged http://openid.net/specs/openid-attribute-exchange-1_0-04.html to be more concise and list URLs for the existing SREG parameters. This will thus show an easy upgrade path between SREG and AX. All through this process it is also important to discuss it on this list and drive consensus with the community. In some senses, I think parts of my objections to AX are how it seems like it has just been shoved down my throat over the past six months. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 03, 2007 10:00 PM To: Recordon, David Cc: Josh Hoyt; OpenID specs list Subject: Re: SREG namespace URI rollback I can see an OP thinking that AX is a big step, but have a hard time seeing it to be that big for an RP (once there are libraries that support AX) ... and it is really not that much more to do AX over SREG for an RP. Where you thinking OP or RP David? -- Dick On 3-Apr-07, at 12:17 PM, Recordon, David wrote: I see there being a gap between SREG and AX with nothing bridging it. IMHO, AX takes too large of a step for people to use it if they just want a few more SREG fields. I think we need something which does nothing more than provide a way to extend SREG and that will solve the majority of problems today. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Monday, April 02, 2007 7:16 PM To: Recordon, David Cc: Johnny Bufu; OpenID specs list Subject: Re: SREG namespace URI rollback On 4/2/07, Recordon, David [EMAIL PROTECTED] wrote: Sure, though I think there has also been a desire to do a bit of an actual rev to SREG to be more of a 1.1 version in terms of either explicitly supporting additional fields (such as avatar) or allowing field names to be URIs themselves versus a hard-coded list of properties. -1 SREG works because it's so dead simple. Attribute exchange is not much more complicated, and it lets you specifiy field names with URIs *and* allows you to define any attributes you see fit. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Moving AX Forward (WAS RE: SREG namespace URI rollback)
Hey Johnny, I agree that you're doing a good job especially with your pre-draft 5 review message. Let's continue that way! There have been things in the past, not that you've done, which have certainly rubbed me the wrong way about AX. Does seem like we're all moving forward though with good progress. One thing that I do think would be worthwhile in smoothing more of this SREG/AX confusion would be adding SREG support to Sxip's OpenID libraries. Any thoughts on spec consolidation and seperating policy from technology? --David -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 04, 2007 12:09 PM To: Recordon, David Cc: Dick Hardt; OpenID specs list Subject: Re: SREG namespace URI rollback David, On 4-Apr-07, at 11:43 AM, Recordon, David wrote: - Cleanup the newly merged http://openid.net/specs/openid-attribute-exchange-1_0-04.html to be more concise and list URLs for the existing SREG parameters. This will thus show an easy upgrade path between SREG and AX. I think this is a good idea - to add a note / paragraph outlining clearly the upgrade path from SREG to AX. All through this process it is also important to discuss it on this list and drive consensus with the community. In some senses, I think parts of my objections to AX are how it seems like it has just been shoved down my throat over the past six months. Not sure what *exactly* you mean with the above, but at least for the least 3 months or so we've been trying to get the community involved with AX, on the lists here: http://openid.net/pipermail/specs/2007-January/001141.html http://openid.net/pipermail/specs/2007-February/001283.html http://openid.net/pipermail/specs/2007-March/001385.html Is there something in particular about the way we handled this that doesn't seem right to you? If yes - what exactly do you think should be done differently? Thanks, Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Promoting OpenID
People might be, though nothing real formal that I personally know of. You volunteering? :P --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McGovern, James F (HTSC, IT) Sent: Monday, April 02, 2007 8:15 AM To: specs@openid.net Subject: Promoting OpenID As an end-user to user-centric approaches, I have noticed an interesting pattern. Microsoft does a wonderful job of selling Cardspace as a solution to others who develop in Microsoft languages. Likewise, there are tons of vendors that can offer solutions for large enterprises to purchase but no one is promoting user-centric approaches to the vendors us large enterprises do business with in terms of getting them to embrace user-centric approaches within their own code base. Sure, we can as consumers raise awareness, but I would like to understand thoughts on other than procurement, how could we make this more pervasive? Is anyone here working with vendors in the ERP, CRM, ECM, BPM or VRM spaces such that user-centric identity is built into their product? * 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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: SREG namespace URI rollback
Sure, though I think there has also been a desire to do a bit of an actual rev to SREG to be more of a 1.1 version in terms of either explicitly supporting additional fields (such as avatar) or allowing field names to be URIs themselves versus a hard-coded list of properties. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johnny Bufu Sent: Monday, April 02, 2007 5:06 PM To: Josh Hoyt Cc: OpenID specs list Subject: Re: SREG namespace URI rollback After a chat with Josh, we settled our dispute by agreeing on the following: On 2-Apr-07, at 2:44 PM, Josh Hoyt wrote: I think it would be reasonable to always use sreg, if for no other reason than for clarity, but re-using the Type URI as the namespace alias instead of creating a new one does not imply that the alias must be sreg when using OpenID 2. What if I put my proposal this way: If Simple Registration is used with OpenID 1, the arguments MUST be prefixed with openid.sreg. If Simple Registration is used with OpenID 2, the arguments MUST be in the namespace http://openid.net/sreg/1.0; The first bit allows a implementation of SREG1.1/OpenID2 to be seamlessly used in compatibility mode with OpenID1 messages, which (together with the last two items in the proposal) would eliminate the conflicts I was pointing out. Johnny ___ 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: Proposal for Modularizing Auth 2.0 Discovery
I agree. I think it is great having a way for people to easily propose new identifier formats and even use them within their own implementations. There does however need to be some sort of community review process before new identifiers are added to OpenID in a public fashion. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Friday, March 02, 2007 12:47 PM To: specs@openid.net Subject: Re: Proposal for Modularizing Auth 2.0 Discovery While I'm strongly in favor of modularization from an architectural perspective, is there a potential security problem here if multiple protocols are developed to resolve the same kind of identifier? (because they could resolve to a different set of endpoints / services) It appears to me that the only way this can work is that while we modularize, we only let the same set of people who have defined some of the plug-in documents define new plug-in documents how to do discovery. The Yadis decentralized innovation model -- everybody define the service types they like, they don't need to ask anybody -- may not work here. Or am I off-base? Cheers, Johannes. Johannes Ernst NetMesh Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Modularizing Auth 2.0 Discovery
+1, I'm fully in support of this and actually have been wanting to do so for quite a number of weeks now! --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Wednesday, February 28, 2007 10:44 AM To: specs@openid.net Subject: Modularizing Auth 2.0 Discovery Recently there has been talk about using alternative identifiers for OpenID, such as email addresses and Jabber Identifiers. This has made it obvious that the OpenID Authentication protocol doesn't care in the slightest what the identifier is as long as service discovery can be performed on it somehow. Currently the Authentication 2.0 specification has language in various places that constrains it to URIs with the schemes http, https and xri. For example, under Terminology the following definition is given for Identifier: An Identifier is either a http or https URI, (commonly referred to as a URL within this document), or an XRI [XRI_Syntax_2.0]. This document defines various kinds of Identifiers, designed for use in different contexts. My proposal is that we make the core Auth 2.0 spec scheme-agnostic. It would just state that an identifier is a URI. Later in the spec, where currently it enumerates a bunch of ways to do discovery, it'd just say do discovery on the URI using an appropriate protocol. (or, indeed, words to that effect.) It would also nominate a standard XRDS service type URI to use during Yadis discovery. Then we'd publish in parallel the following two ancillary specifications: * OpenID Discovery for HTTP and HTTPS URIs * OpenID Discovery for XRI URIs. Later, the OpenID community or a third party could publish a specification OpenID Discovery for Email Addresses, but I don't think we're really ready to go there right now. The discovery protocols don't necessarily need to be XRDS-based, but if they are they would presumably reference the standard service type URI from the Auth spec so that future Auth versions can change this without needing to re-publish the discovery specs. This has the following benefits: * It gives others a clear, spec-approved mechanism to bolt-on support for additional URI schemes. * It allows the Authentication specification to evolve separately from the various discovery specifications, which are unlikely to need to change very much from version-to-version. * It formalizes the separation between discovery and authentication, giving library authors a clear plug-in point if they wish to support modular discovery. Presumably the OpenID Auth 2.0 spec would still retain a reference to the HTTP and HTTPS discovery spec purely so that it can say that RPs MUST support it regardless of what else they support. - All ancillary discovery specifications must, at minimum, define: * A pattern for recognizing and canonicalizing their own identifiers. (For example, the XRI one would include a provision for checking for an identifier which starts with a global context symbol, etc.) * A mechanism for returning the following information: - Either: (traditional identity case) * Canonical Claimed identifier (an i-number, for example) * User-supplied Display identifier (an i-name, for example) * OP endpoint URL * OP-local identifier (i.e. openid:Delegate as was) - Or: (directed identity case) * OP endpoint URL * Canonical OP identifier (for use in confirmation messages) (And, of course, not all discovery mechanisms would necessarily support directed identity.) ___ 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: Modularizing Auth 2.0 Discovery
Well there already is the Yadis spec. Maybe the Yadis spec remains separate versus becoming part of the OASIS XRI Resolution document? --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Wednesday, February 28, 2007 11:59 AM To: specs@openid.net Subject: Re: Modularizing Auth 2.0 Discovery Martin Atkins wrote: My proposal is that we make the core Auth 2.0 spec scheme-agnostic. Attached is a version of the current spec draft 11 with large chunks of the discovery/normalization stuff hacked out and replaced with generic see other specifications text. I think I may have deleted too much in that we've lost the detailed rules for dealing with XRDS documents, which are probably going to be referenced by most discovery specs and deserve to be in the core spec. See the TODO: markers for more info. However, in doing this it also occured to me that it would be very useful to have the XRDS-related bits of the XRI resolution spec in a separate document that we could reference, since our new protocol-agnostic core Auth 2.0 spec has no need for the rest of XRI resolution. I wonder if the XRI guys would consider making Chapter 3 of the XRI Resolution 2.0 spec into a separate document that OpenID Auth could reference directly? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Modularizing Auth 2.0 Discovery
Works for me, one thing though is the Yadis spec specifically highlights the bits of the XRDS file which are relevant in this sort of use case. If chapter 3 is separate then this would be a smaller concern for me, but I think part of the *ugh* feeling people get is having to read about the full XRDS schema. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Wednesday, February 28, 2007 12:17 PM Cc: specs@openid.net Subject: Re: Modularizing Auth 2.0 Discovery Recordon, David wrote: Well there already is the Yadis spec. Maybe the Yadis spec remains separate versus becoming part of the OASIS XRI Resolution document? The XRDS-related parts of the Yadis specification seem to duplicate requirements from XRI Resolution chapter 3. In the interests of avoiding redundancy, I'd suggest the following distinction: 1. XRI Resolution chapter 3 (or a separate spin-off spec) describes the syntax of an XRDS document. 2. Yadis describes how to obtain an XRDS document for an HTTP or HTTPS URL. 3. OpenID Authentication describes how to determine the endpoint URI and other information from an XRDS document, referencing [1]. 4. The new HTTP discovery specification would reference [2] and [3] to describe the XRDS-based HTTP discovery mode, and then go on to describe the HTML-based discovery fallback. Alternatively, [3] above could be served by a separate spec OpenID discovery using XRDS, though I think that may be overkill for something so straightforward. ___ 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: Modularizing Auth 2.0 Discovery
I'd be happy with either approach. One spec with a section on each type or separate specs for each. I think small separate specs are slightly harder to comprehend, though make it easer for things like the SMTP extension to develop. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Wednesday, February 28, 2007 12:24 PM Cc: specs@openid.net Subject: Re: Modularizing Auth 2.0 Discovery Drummond Reed wrote: Under this approach, discovery all identifiers (URLs, XRI i-names/i-numbers, email addresses, phone numbers, etc.) would be handled by OpenID Discovery. I disagree that a single spec can contain discovery rules for all conceivable discovery types without becoming ridiculously big. The discovery rules in the current spec for just handling HTTP/HTTPS and XRI discovery are already big enough. However, I clearly have a bias for lots of small specs over one large spec, and clearly your bias is the opposite. :) ___ 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: Modularizing Auth 2.0 Discovery
Yeah, I'd see this either as a Yadis 1.1 (using things like LocalID versus OpenID:Delegate) or have the OpenID URL Discovery spec replace Yadis, referencing chapter 3 as needed. I think I'd lean toward swallowing Yadis in as a part of this spec so it is one fewer documents people need to read in total. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Wednesday, February 28, 2007 12:27 PM To: specs@openid.net Subject: Re: Modularizing Auth 2.0 Discovery Recordon, David wrote: Works for me, one thing though is the Yadis spec specifically highlights the bits of the XRDS file which are relevant in this sort of use case. If chapter 3 is separate then this would be a smaller concern for me, but I think part of the *ugh* feeling people get is having to read about the full XRDS schema. Perhaps then Yadis (or something else) can describe the subset of the XRDS schema used for service discovery, referencing the full XRDS specification only as a formality? I agree that XRI Resolution chapter 3 is a bit big for our purposes. ___ 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: Modularizing Auth 2.0 Discovery
I'd like to stay away from changing it much, but I do agree there are some warts which have been found. Also by taking advantage of things in the XRDS schema which exist now such as the LocalID element we'd be able to remove the OpenID XMLNS for example. --David -Original Message- From: rob [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 28, 2007 1:03 PM To: Recordon, David Cc: Martin Atkins; specs@openid.net Subject: Re: Modularizing Auth 2.0 Discovery Recordon, David wrote: I think I'd lean toward swallowing Yadis in as a part of this spec so it is one fewer documents people need to read in total. +1 does this open up the potential to change Yadis? I certainly found the spec confusing on a few points when I first read it i.e. 1) Two xml namespaces, why? 2) Confusing namespace names, xri://$xrd*($v*2.0) this is just plain confusing for someone not familiar with i-names. 3) Then finally this text If a Yadis XRDS includes more than one XRD element, the Yadis Resource Descriptor is the last XRD element. A Relying Party Agent MAY ignore other XRD elements. Again, just confused me, couldn't see the point of the seemingly redundant xrd element or understand when there would be more than one. / /Rob ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Proposal: An anti-phishing compromise
Maybe laws are meant to be broken. I don't see why a RP knowing that I used a token as a second factor is a bad thing. If nothing else, the technology should support the OP providing that information and the OP's implementation can let me as the user decide if I want to. Just like the trust request, it isn't mandated by the spec but every worthwhile OP does it. My $0.02. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Sunday, February 04, 2007 11:42 PM To: Granqvist, Hans Cc: OpenID specs list Subject: Re: Proposal: An anti-phishing compromise On 1-Feb-07, at 2:36 PM, Granqvist, Hans wrote: Add a single, required, boolean field to the authentication response that specifies whether or not the method the OP used to authenticate the user is phishable. The specification will have to provide guidelines on what properties an authentication mechanism needs to have in order to be non-phishable. The field is just meant to indicate that the authentication mechanism that was used is not a standard secret entered into a Web form. The receiver should decide what is 'non-phishable', not the sender, so it would be better if the OP just states what mechanism was used, perhaps. Per Kim's laws, how I authenticate to my OP is none of the RP's business. That I authenticated in a phishing resistant manner is. ie. we want the OP to make the statement that it followed certain anti-phishing guidelines. There is no certainty that the OP followed them, but the RP and user have recourse against an OP if the OP stated that it did follow the anti-phishing guidelines. -- 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: Proposal: An anti-phishing compromise
I agree that things like age should be in an extension, though I think this single piece of data is useful in the core protocol. I'm sure the exact definition of phishing resistant will come back to bite us in sometime in the future, but lets deal with it then instead of not adding anything now. I really like the idea that there be one thing in the core spec which reaches out to each extension. - openid.identity - simple reg or profile exchange (on the basis that the URL is an attribute) - openid.phishing_resistant - AQE I think this is a good model to follow. From the AQE perspective, I agree with you that using URLs for authentication types makes sense, though profiling the entire document beyond that I think is overkill. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Monday, February 05, 2007 12:01 AM To: Josh Hoyt Cc: OpenID specs list Subject: Re: Proposal: An anti-phishing compromise Hi Josh A few comments: 1) I think this should be an extension following previous arguments that AuthN Age should be an extension. (AuthN Age would be another good item in this extension) This allows an OP to advertise if it supports a specific security profile. 2) It would be future proofing to view a phishing resistance as one of many security profiles. Strong Authentication could be another one. 3) The RP should be able to request that one of more security profiles are used. Not all RPs will require a particular profile, so provides a nice security gradient. 4) The phishing resistant profile should be a URI, so that new ones can be created in the future. The profile would not state specifically how authentication was done, but would set a bar on what needed to be done to provide a level of assurance that the user had not been phished. As technology advances, new security profiles will likely be developed, which could then be deployed, advertised by the OP, and requested by RPs Summary of process: RP does discovery on OP to see if it supports the desired security profile. If the profile is not supported by the OP, then the RP may abort the transaction and provide the user with The RP expresses the desired security profile in the request. eg.: openid.sp.request=http://specs.openid.net/sp/phishing-resistant-A The OP executes on the desired security profile and states it has in the response. eg.: openid.sp.response=http://specs.openid.net/sp/phishing-resistant-A The RP checks the security profile in the response and proceeds accordingly. On 1-Feb-07, at 1:41 PM, Josh Hoyt wrote: Hello, I've written up a proposal for an addition to the OpenID Authentication 2.0 specification that addresses the phishing problem. I've had some off-list discussion of it, and I think it may strike the right balance. Please provide feedback. Josh Background == We have had a lot of good discussion about how phishing relates to OpenID. There seems to be consensus that the OpenID Authentication spec should address these issues, but not consensus on how that should happen. The ways that OpenID can potentially make phishing worse: * Redirects to your provider are a fundamental part of the flow of OpenID, so being redirected to a phishing site is easy to miss * Every relying party (necessarily) needs to know who the provider is in order to verify the authentication response. This means that the site knows what UI it needs to use to phish (and even worse, it can just proxy the user to the provider) I think these two issues cover what makes phishing potentially a greater threat when using OpenID. Although these problems are significant, if a user can authenticate to their OpenID provider through an non-phishable mechanism, OpenID can make the phishing problem *less* of a threat, because there are fewer places that will need to ask for credentials. Other relevant issues: * There is no universally deployed solution to the phishing problem * There is not even a universally *accepted* solution to the phishing problem * Any technology that prevents phishing will require user-agent support or else will fundamentally change the flow of OpenID (prevent relying-party-initiated sign-in) * OpenID is intended to be deployed without requiring specific technologies to be present in the user-agent * Any general anti-phishing technology can be applied to OpenID Proposed Change === Add a single, required, boolean field to the authentication response that specifies whether or not the method the OP used to authenticate the user is phishable. The specification will have to provide guidelines on what properties an authentication mechanism needs to have in order to be non-phishable. The field is just meant to indicate that the authentication mechanism that was used is not a standard secret entered into a Web form. Analysis This
RE: Proposal: An anti-phishing compromise
Rogue RPs can already go and find RPs out there and manually look to see which just use usernames and passwords. I don't see how providing this information actually makes the issue worse. I agree that it makes it more apparent, but I'd hope that it would scare users and get them to go use a better OP. An OP lying only hurts its users. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Claus Färber Sent: Friday, February 02, 2007 5:01 AM To: specs@openid.net Subject: Re: Proposal: An anti-phishing compromise Recordon, David [EMAIL PROTECTED] schrieb/wrote: Add a single, required, boolean field to the authentication response that specifies whether or not the method the OP used to authenticate the user is phishable. The specification will have to provide guidelines on what properties an authentication mechanism needs to have in order to be non-phishable. The field is just meant to indicate that the authentication mechanism that was used is not a standard secret entered into a Web form. What should the RP do with that flag? If they lock out users who are phishable, OP will simply start to lie about their non-fishability. The main problem, however, is that it actually adds to the phishing problem by providing rouge RPs valueable information about security risks. Claus ___ 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: Proposal: An anti-phishing compromise
I'm in support of this idea. I think a single parameter in the OP's response will pave the path to integrate solutions to the phishing problem and scales up to the AQE extension as it is re-worked. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Thursday, February 01, 2007 1:42 PM To: OpenID specs list Subject: Proposal: An anti-phishing compromise Hello, I've written up a proposal for an addition to the OpenID Authentication 2.0 specification that addresses the phishing problem. I've had some off-list discussion of it, and I think it may strike the right balance. Please provide feedback. Josh Background == We have had a lot of good discussion about how phishing relates to OpenID. There seems to be consensus that the OpenID Authentication spec should address these issues, but not consensus on how that should happen. The ways that OpenID can potentially make phishing worse: * Redirects to your provider are a fundamental part of the flow of OpenID, so being redirected to a phishing site is easy to miss * Every relying party (necessarily) needs to know who the provider is in order to verify the authentication response. This means that the site knows what UI it needs to use to phish (and even worse, it can just proxy the user to the provider) I think these two issues cover what makes phishing potentially a greater threat when using OpenID. Although these problems are significant, if a user can authenticate to their OpenID provider through an non-phishable mechanism, OpenID can make the phishing problem *less* of a threat, because there are fewer places that will need to ask for credentials. Other relevant issues: * There is no universally deployed solution to the phishing problem * There is not even a universally *accepted* solution to the phishing problem * Any technology that prevents phishing will require user-agent support or else will fundamentally change the flow of OpenID (prevent relying-party-initiated sign-in) * OpenID is intended to be deployed without requiring specific technologies to be present in the user-agent * Any general anti-phishing technology can be applied to OpenID Proposed Change === Add a single, required, boolean field to the authentication response that specifies whether or not the method the OP used to authenticate the user is phishable. The specification will have to provide guidelines on what properties an authentication mechanism needs to have in order to be non-phishable. The field is just meant to indicate that the authentication mechanism that was used is not a standard secret entered into a Web form. Analysis This proposal is a simplification of the Assertion Quality Extension [1] (AQE), and is essentially the same as what Ben Laurie proposed earlier [2]. It does not attempt to replace the AQE or require it for authentication in general. Benefits The proposal is trivial implement, it acknowledges that phishing is a problem, and forces implementers think about it. If more assurances are required, then the AQE, whitelists, and other mechanisms still need to be employed. This field just sets a minimum bar. I think that this is the right information to require, because it addresses this one thing that makes OpenID potentially worse for security, but it does not mandate specific technologies. It pushes the liability for phishing relying parties to OpenID providers, who are the ones who should be responsible for taking measures to prevent phishing. IANAL, so I don't know if this has any real teeth, but it does make it clear to people who are implementing OpenID providers that it is intended to be their responsibility to deal with the phishing issues. Drawbacks - It may be tricky to define what is meant by non-phishable. There is no way for a Relying Party to *ensure* that the OpenID provider indeed uses non-phishable authentication. If libraries are used, the library user may not read the relevant parts of the specification about phishing, and so may remain ignorant of the phishing issues. Why this should be in the core spec --- I believe that this one piece of information would be required more often than not, given the phishing implications. The prominence of being in the core specification makes it harder to ignore the phishing problem. References == 1. http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html 2. http://openid.net/pipermail/general/2007-January/001340.html ___ 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: Proposal: An anti-phishing compromise
I think we all agree that talking about the method used is far more useful, though with this proposal we're really trying to balance it with simplicity in the authentication protocol itself. Maybe it is better to phrase the discussion around if the user provided a secret (password) to the OP or not to authenticate versus talking about phishing directly.?. I'd hope that this parameter in the auth spec really helps bring the discussion around to the Assertion Quality Extension and that it be implemented to provide the more robust metadata such as what type of authentication was actually preformed. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of john kemp Sent: Thursday, February 01, 2007 7:13 PM To: Granqvist, Hans Cc: OpenID specs list Subject: Re: Proposal: An anti-phishing compromise Granqvist, Hans wrote: Proposed Change === Add a single, required, boolean field to the authentication response that specifies whether or not the method the OP used to authenticate the user is phishable. The specification will have to provide guidelines on what properties an authentication mechanism needs to have in order to be non-phishable. The field is just meant to indicate that the authentication mechanism that was used is not a standard secret entered into a Web form. The receiver should decide what is 'non-phishable', not the sender, so it would be better if the OP just states what mechanism was used, perhaps. Agreed. A statement as to the phishability or not seems to be too vague to be useful. A simple statement of the authentication method used would seem to give the same effect, while providing potentially useful information (assuming the RP trusts statements from the OP at all.) Benefits ... Here's what I think: Since the association step is hardly ever used, it can much more easily be overloaded with extra information without breaking any implementation. If the OP would *require* an OpenID association step from the RP, then this step can include an exchange of meta-information between OP and RP. How does the association step between OP and RP change the relationship between the OP and the user (agent)? I thought the attack we were considering is when a rogue RP directs the user agent to a rogue OP, who then steals the user's credentials? How is that affected by the rogue RP and rogue OP associating? - John ___ 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: DRAFT 11 - FINAL?
I'm happy changing it from AJAX. I think it was originally used since AJAX is a bit overloaded already and people normally understand the flashy non-reloading sort of thing when saying it. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rowan Kerr Sent: Wednesday, January 31, 2007 12:50 PM To: specs@openid.net Subject: Re: DRAFT 11 - FINAL? On 1/31/07, Martin Atkins [EMAIL PROTECTED] wrote: I think the spec is misusing the AJAX abbreviation a bit here, since the usual approach to doing this doesn't involve XMLHttpRequest at all, but instead works something like this: *snip* Yeah I've implemented a pure javascript demo this way (which works if the OP does a http redirect back to the RP instead of submitting a form). So no, this isn't really AJAX in the usual sense. As you noted, you can't do OpenID Auth client-side with XMLHttpRequest because of the same-origin restriction. You also can't do OpenID on the server because then the user's session cookie won't end up at the OP during the request. It still achieves the desired effect of doing an OpenID auth request without disturbing the current page, though. So should wording other than AJAX be used in the spec? Or do we just point to an explanation on the wiki. -Rowan ___ 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: Tiny RDF Schema at openid.net?
I'm not an RDF/OWL expert, though that looks reasonable to me. How do we deal with Auth 1.x which uses openid.server and openid.delegate versus Auth 2.0 which uses openid2.provider and openid2.local_id? --David -Original Message- From: Benjamin Nowack [mailto:[EMAIL PROTECTED] Sent: Monday, January 29, 2007 10:13 AM To: Recordon, David; Scott Kveton; specs@openid.net Cc: [EMAIL PROTECTED] Subject: RE: Tiny RDF Schema at openid.net? On 29.01.2007 07:53:15, Recordon, David wrote: I'd be happy to do it; I think we were talking about using xmlns.openid.net/foo as a format. Awesome :) I think the next step would be sending a copy of the RDF file for people here to look over. :) I've attached a draft which contains already some nice2haves (e.g. the OWL and isDefinedBy bits which may be helpful but are not strictly necessary), I'm not 100% sure about the prose, and I guess DanC will have a comment or two as well. (The resource/about/ID attributes work similar to HTML's href/id, they use the doc's URL as base, i.e. if the file was published at http://xmlns.openid.net/auth, the full term URIs would be http://xmlns.openid.net/auth#server etc.) [[[ ?xml version=1.0? rdf:RDF xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#; xmlns:rdfs=http://www.w3.org/2000/01/rdf-schema#; xmlns:owl=http://www.w3.org/2002/07/owl#; owl:Ontology rdf:about= rdfs:labelOpenID Authentication Schema/rdfs:label owl:versionInfo2007-01-29/owl:versionInfo rdfs:comment A basic schema for core OpenID authentication terms. /rdfs:comment /owl:Ontology rdf:Property rdf:ID=server rdf:type rdf:resource=http://www.w3.org/2002/07/owl#ObjectProperty/ rdfs:labelserver/rdfs:label rdfs:comment The OpenID Identity Provider to be used for authentication. /rdfs:comment rdfs:isDefinedBy rdf:resource=http://openid.net/specs/openid-authentication-1_1.html; / /rdf:Property rdf:Property rdf:ID=delegate rdf:type rdf:resource=http://www.w3.org/2002/07/owl#ObjectProperty/ rdfs:labeldelegate/rdfs:label rdfs:comment The delegated OpenID Identifier to be used for authentication. /rdfs:comment rdfs:isDefinedBy rdf:resource=http://openid.net/specs/openid-authentication-1_1.html; / /rdf:Property /rdf:RDF ]]] Best, Ben Thanks, --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Kveton Sent: Monday, January 29, 2007 7:42 AM To: Benjamin Nowack; specs@openid.net Cc: [EMAIL PROTECTED] Subject: Re: Tiny RDF Schema at openid.net? With just a quick look at this, it seems like a good idea. I'd like to see it happen somehow. Anybody see any problems with doing this? - Scott On 1/29/07 2:13 AM, Benjamin Nowack [EMAIL PROTECTED] wrote: Hi, I was wondering if you guys could be persuaded to host a little RDF Schema file on the openid.net site. As far as I can tell, there is great support for OpenID among SemWeb folks as it can be combined with things like FOAF for all sorts of cool applications. People recently started to write RDF extractors for the OpenID hooks embedded in HTML (openid.server/delegate). As these hooks are in line with the Dublin Core guidelines [1], there are even multiple ways to do this. The only thing we're missing for more widespread use is an agreed-on namespace URI for the core openID terms (server and delegate). And ideally this would be an openid.net one. So here is my request: any chance we could put a little RDF Schema file on the openid server? We would of course provide the file (it'd be just 5-10 lines of XML), and the actual URL/path doesn't really matter. An alternative could be to host it in some other stable URI space, Dan Connolly (CC'd) might be able to provide one at w3.org, not sure. It would be cool to get your blessing either way, though. Cheers in advance for perhaps considering it, Ben -- Benjamin Nowack Kruppstr. 100 45145 Essen, Germany http://www.bnode.org/ [1] http://www.dublincore.org/documents/dcq-html/ ___ 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: OpenID Auth 2.0 security considerations
Is there a wiki page that exists to point to? Josh and Johnny, see any issues with this? Also any wording to propose Johannes? Thanks, --David -Original Message- From: Johannes Ernst [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 23, 2007 12:57 PM To: Recordon, David Cc: specs@openid.net Subject: Re: OpenID Auth 2.0 security considerations Given where we are in time, I would suggest to make the smallest amount of changes possible to the document, i.e. leave everything as is, just add this one link. On Jan 23, 2007, at 11:59, Recordon, David wrote: I don't see a problem with that. Would you propose the majority of the security considerations section in the current draft be moved to the wiki? What would be the balance between spec and wiki page? --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Monday, January 22, 2007 12:15 PM To: specs@openid.net Subject: OpenID Auth 2.0 security considerations What about a non-normative link from the spec to a place on the wiki where we can collect security considerations for it, and update those in real-time as discussions such as the phishing one progress. ___ 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: DRAFT 11 - FINAL?
Yeah, I'm not a big fan of openid2.* though it was the simplest method of fixing up HTML discovery to work with multiple protocol versions. I know Josh thought about this more than I did though. From what I've seen people do, it is AJAX between your server and application, then OpenID's checkid_immediate between the server and OP, with an AJAX response from your server to application. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rowan Kerr Sent: Tuesday, January 30, 2007 2:02 PM To: specs@openid.net Subject: Re: DRAFT 11 - FINAL? The openid2.* links bug me a little.. but due to no openid.ns being defined in the 1.x protocol, maybe there is no other way to specify by HTML discovery that your OP is 2.0 capable. Would it be bad to have a openid.version link instead? Also, the spec mentions AJAX interactions, but I don't see how you can actually use AJAX with OpenID, since none of the responses are in XML format .. it relies entirely on GET or POST redirection, not to mention that you have to make cross-domain requests which XmlHttpRequest will not do without extra security privileges. (Or am I missing something?) -Rowan ___ 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.0 Spec Questions
James, for 3 have you looked at http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html? I don't think it addresses the specific point you brought up, though may be the right place to do it. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James McGovern Sent: Sunday, January 21, 2007 4:49 PM To: specs@openid.net Subject: 2.0 Spec Questions Sensitivity: Confidential Several questions after reading the 2.0 spec - draft 11. 1. The definition of realm if I am reading it correctly could be problematic in large enterprises. For example, if one were using a web access management product, they would have the ability to define a realm in terms of a listing of discrete hosts that may or may not fit a URL pattern matching approach. For example, I could have a demographic called consumers who could access hosts such as http://myconsumer.example.com , http://printstatements.example.com, http://paybills.example.com Likewise another demographic called Business Partner may have a different set of hosts they can interact with. 2. In terms of checking the nonce, can we recommend that a deployment practice should be to use the NTP protocol and point to clocks of a certain stratum? Likewise, would it be a good idea if an association could indicate how much skew it would accept before rejecting? 3. In terms of an extension, should an OP be able to indicate when reauth may be required so the user doesn't assume that if they authenticate once they are always good? 4. Some portions of the spec are heavily coupled to PKI. How should growing users of IBE think of this? ___ 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: [OpenID] CROSS POSTING :-(
I'd have to agree. I realize I am guilty for the start of this thread announcing the new spec draft, though am hoping we can move this discussion to [EMAIL PROTECTED] if that works for people. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gabe Wachob Sent: Monday, January 22, 2007 11:05 AM To: heraldry-dev@incubator.apache.org; [EMAIL PROTECTED]; specs@openid.net; 'openid-general' Subject: [OpenID] CROSS POSTING :-( This is getting a little insane - many of us are subscribed to the four lists that this thread has been posted to. One person has suggested that we actually consolidate the separate lists given the overlap in membership and topics (at least the openid lists). The other option is to be more disciplined about posting. In any case, having most threads cross posted to 4 lists seems insane and unworkable to me. What's the mood on consolidating the lists? I'd rather we just be careful about cross posting and keep the separate lists, but that may be too much to ask. -Gabe P.S. Yes, I realize this is cross posted ;-) -Original Message- From: Marcin Jagodziński [mailto:[EMAIL PROTECTED] Sent: Monday, January 22, 2007 10:47 AM To: Ben Laurie Cc: Josh Hoyt; [EMAIL PROTECTED]; specs@openid.net; openid-general; heraldry-dev@incubator.apache.org Subject: Re: [security] [OpenID] Announcing OpenID Authentication 2.0 - Implementor's Draft 11 2007/1/22, Ben Laurie [EMAIL PROTECTED]: Actually, it appears to allow the RP to tell the OP what kind of authentication was used, which is backwards. It also seems to be rather lacking in meat. Still, a step in the right direction. I asked this question some time ago: is there any possibility for RP to ask OP to use some authentication method? Or another scenario: how can user select one of OP's for this particular authentication from his Yadis file. regards, Marcin ___ general mailing list [EMAIL PROTECTED] http://openid.net/mailman/listinfo/general ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Announcing OpenID Authentication 2.0 - Implementor's Draft 11
I'm not sure what the right process is, though my hunch is that we'll know the time is right once there are multiple working OpenID Auth 2.0 RPs and OPs on the web from different vendors that people are at least testing with. Until code that implements the spec exists in the wild, I doubt we can really ultimately call it final. That's just my take on it though... --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Thursday, January 18, 2007 11:38 PM To: heraldry-dev@incubator.apache.org Cc: openid-general; specs@openid.net Subject: Re: Announcing OpenID Authentication 2.0 - Implementor's Draft 11 David A couple questions: 1) Would you like to set a deadline for final comments? Perhaps a week? 2) What is the approval process now? Is it still as posted at: http://openid.net/specs.bml Currently, the collective authors of OpenID Authentication (David Recordon, Josh Hoyt, Dick Hardt, and Brad Fitzpatrick) oversee this process and make the final determination of when a proposal has matured. -- Dick On 18-Jan-07, at 7:35 PM, Recordon, David wrote: So with great pleasure I get to announce the culmination of about nine months of work between the OpenID, XRI, Sxip, and LID communities in the drafting of OpenID Authentication 2.0. This evening the editors have published the final draft of the spec, which we now feel is in a solid state for public implementations. There are already implementations in various languages (http://svn.apache.org/repos/asf/incubator/heraldry/libraries/, http://code.google.com/p/openid4java/, http://code.google.com/p/openid4perl/) supporting this spec and more will emerge over the next few weeks. There will be another draft of the spec before it is considered final, though unless unforeseen implementation problems emerge these changes will be further wordsmithing and cleanup. http://openid.net/specs/openid-authentication-2_0-11.html (dated today) Cool? Cool! --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: DRAFT 11 - FINAL?
Considering draft 11 hasn't been published yet, I don't see how we can make it final at this point. In addition, the file you link to is a few patches old. While I appreciate your enthusiasm, Josh, Johnny, and I do have a process to this madness. I know you know that we're really close, there is one remaining issue Josh, Drummond, and I are tackling this afternoon, and then we'll publish draft 11. Thanks, --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Thursday, January 18, 2007 3:45 PM To: specs@openid.net Subject: DRAFT 11 - FINAL? Hey List To deal with the recent security concern postings about OpenID, language was added to clarify a secure channel is needed between the OP and the end-user's machine. Are there any more issues with this specification: http://openid.net/specs/openid-authentication-2_0-11.html Can we make this final? -- 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
Announcing OpenID Authentication 2.0 - Implementor's Draft 11
So with great pleasure I get to announce the culmination of about nine months of work between the OpenID, XRI, Sxip, and LID communities in the drafting of OpenID Authentication 2.0. This evening the editors have published the final draft of the spec, which we now feel is in a solid state for public implementations. There are already implementations in various languages (http://svn.apache.org/repos/asf/incubator/heraldry/libraries/, http://code.google.com/p/openid4java/, http://code.google.com/p/openid4perl/) supporting this spec and more will emerge over the next few weeks. There will be another draft of the spec before it is considered final, though unless unforeseen implementation problems emerge these changes will be further wordsmithing and cleanup. http://openid.net/specs/openid-authentication-2_0-11.html (dated today) Cool? Cool! --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Identity Based Encryption
Hi James, There has been some discussion, though normally around DTP http://openid.net/specs/openid-service-key-discovery-1_0-01.html, http://openid.net/specs/openid-dtp-messages-1_0-03.html, http://openid.net/pipermail/specs/2007-January/001104.html. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James McGovern Sent: Saturday, January 06, 2007 3:43 AM To: specs@openid.net Subject: Identity Based Encryption Sensitivity: Confidential One of the things that is on my radar is the move towards identity-based encryption (http://crypto.stanford.edu/ibe/). I am curious if anyone hear has explored how it can work with OpenID? Hopefully we aren't assuming PKI only? Has anyone invited the folks from Stanford and/or Voltage to participate? If not, I will. ___ 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: OpenID.net Service Type Namespaces
Bringing this back up as now with more extensions I think we need at least some sort of naming scheme. I'd propose we use for roots: http://specs.openid.net/authentication/VERSION... http://specs.openid.net/extensions/ABBREV/VERSION... Then corresponding: http://xmlns.openid.net/extensions/ABBREV/VERSION/... I'd lean against a date based naming scheme since it means that authors always need to remember to update for each draft as well as library developers writing code. So for OpenID Authentication 2.0, I think this is basically the time to change it or we leave it forever. This means for the auth spec we would have: http://specs.openid.net/authentication/2.0/signon http://specs.openid.net/authentication/2.0/server http://specs.openid.net/authentication/2.0/identifier_select So very verbose and organized. There is no need for an xmlns for the Auth 2.0 spec itself, since unlike the 1.1 spec which defined OpenID:Delegate in Yadis, 2.0 takes advantage of the LocalID element already defined in the XRD schema. I'm obviously +1 for this naming scheme, want to get it right even though we are beyond the eleventh hour. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 1:07 PM To: Recordon, David Cc: Drummond Reed; specs@openid.net Subject: Re: OpenID.net Service Type Namespaces I get the hostname aspect for another namespace. w3c[1] uses: http://www.w3.org/ns/sss http://www.w3.org//MM/ I have no strong opinion on it though [1] http://www.w3.org/2005/07/13-nsuri On 7-Nov-06, at 12:07 PM, Recordon, David wrote: Yeah, that is my concern. Much easier to manage the namespace if this part is separate, then no matter what software is run for openid.net anytime down the road we won't have issues. --David -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 11:56 AM To: 'Dick Hardt'; Recordon, David Cc: specs@openid.net Subject: RE: OpenID.net Service Type Namespaces My understanding is that the concern is with potential conflicts in the actual functioning of openid.net. Creating a clean DNS namespace for specs at specs.openid.net does seem like a good solution to me. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Tuesday, November 07, 2006 8:09 AM To: Recordon, David Cc: specs@openid.net Subject: Re: OpenID.net Service Type Namespaces What is the concern? The argument for keeping it the current way is for consistency. The URL resolution does not need to be trusted does it? On 6-Nov-06, at 5:04 PM, Recordon, David wrote: I'm still concerned with using the openid.net/ namespace. Objections to using http://specs.openid.net/authentication/2.0/signon? We don't need to change this in legacy stuff, just for 2.0 moving forward. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Saturday, October 21, 2006 7:34 PM To: Granqvist, Hans Cc: Recordon, David; specs@openid.net Subject: Re: OpenID.net Service Type Namespaces I am very supportive of an HTTP GET retrieving the specification. I think there are some issues with putting the date in the URL: 1) the URL is unknown until the spec is completed. Any implementations being done during the specification then have a moving target. The URL is embedded in the Yadis document and I can see it causing some headaches for people that it is not fixed until the end. 2) the grouping is by time instead of by specification. If I want to see all versions of a specification, it is not obvious Currently we have: http://openid.net/signon/1.0 http://openid.net/signon/1.1 http://openid.net/server/2.0 http://openid.net/signon/2.0 http://openid.net/identifier_select/2.0 Given that the 1.x ones are already there, I would recommend we keep using that scheme. -- Dick On 20-Oct-06, at 3:39 PM, Granqvist, Hans wrote: It has had some voices against it, but how about considering this template (used in for example W3C xmldsig and xmlenc): http://openid.net/[year]/[month]/[project]#[type] Time-dependent (rather than version--dependent) namespaces can evolve freely and will not be tied down to specific versioning numbers. Example: http://openid.net/2006/10/authentication http://openid.net/2006/10/authentication#signon It's cool if an HTTP GET on these links returns the specification. Once a spec is finalized, the then current year/month becomes that spec's namespace. For example, xmlenc's namespace is http://www.w3.org/2001/04/xmlenc Hans -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Friday, October 20, 2006 3:09 PM To: specs@openid.net Subject: OpenID.net Service Type Namespaces Right now we have things like http://openid.net
RE: Key Discovery In DTP Draft 3
True, though why not still use this XML structure and the RetrievalMethod element within the XRDS so that can then point to a remote KeyInfo element in another XML document? --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grant Monroe Sent: Friday, January 05, 2007 8:31 AM To: Recordon, David Cc: Carl Howells; specs@openid.net Subject: Re: Key Discovery In DTP Draft 3 On 1/4/07, Recordon, David [EMAIL PROTECTED] wrote: Hey guys, Was looking at http://openid.net/specs/openid-service-key-discovery-1_0-01.html tonight and curious why the decision was made to define the PublicKey / element which contains a link to the RSA key or X.509 certificate versus embedding the key in the XRDS file? I believe the rational was that KeyInfo objects can be quite large. Especially if you have multiple services using them. We were concerned about XRDSs getting really large. It doesn't make a whole lot of sense to download a key for a service entry you aren't even interested in. -- Grant Monroe JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] Temporarily redirecting one's identity?
I like this idea of using 307, though haven't thought through all the repercussions of doing so. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Thursday, January 04, 2007 11:27 AM To: [EMAIL PROTECTED] Subject: Re: [OpenID] Temporarily redirecting one's identity? Sam Ruby wrote: Oh, dear. I may have found an edge case. And documented it in a manner that others may follow. The documentation is here: http://www.intertwingly.net/blog/2007/01/03/OpenID-for-non-SuperUsers The issue is that when somebody requests http://intertwingly.net/blog/ and specifies an Accept: application/xrds+xml header on the request, I do a temporary 302 redirect to http://intertwingly.net/public/yadis.xrdf The question is: when the identity validation is done, what should the RP view as my identity? The original URI (.../blog/) or the temporary one (.../yadis.xrdf)? LiveJournal (http://www.livejournal.com/openid/) choses the former. JanRain (http://www.openidenabled.com/resources/openid-test/checkup) choses the latter. IMO, independent of whether or not I should be doing the redirect, the spec should be clear and one or both of these implementations should be changed to conform. My two cents is that the answer should depend on whether it was a permanent redirect (301) or a temporary redirect (302) which was employed. However, if consensus forms on this mailing list, I'll update my tutorial accordingly. I believe that the spec doesn't make any distinction between permanent and temporary redirects: any kind of redirect serves as a canonicalization step (so, for example, http://www.livejournal.com/users/frank/ becomes http://frank.livejournal.com/) and so the ultimate destination URL is used as the claimed identifier. (In other words, LiveJournal is wrong.) I admit that this is a bit irritating, but here's a workaround. Rather than issuing a redirect, you can instead issue a response like this: - HTTP/1.1 200 OK Content-type: text/html X-XRDS-Location: http://intertwingly.net/public/yadis.xrdf Vary: Content-type pa href=http://intertwingly.net/public/yadis.xrdf;XRDS Document/a/p - I will admit that this is ugly[1], but it should work with OpenID/Yadis implementations in the wild today. I don't remember the reason why a temporary redirect was made equivalent to a permanent one, but this was discussed on a previous occasion. Perhaps someone can dig up the relevant thread in the archives. At this point we probably can't make this change due to existing implementations (though admittedly they do seem to be inconsistent right now), so perhaps we could instead use a 307 Temporary Redirect[2] response and retain the existing meaning of 301 and 302. I note that Apache's Redirect directive *is* able to generate this response code. However, I fear that existing implementations might fail when faced with this previously-undefined response code. Yadis is already finished, so it might be too late to add this in now. --- [1] Not least because the client said Accept: application/xrds+xml and we returned a 200 OK (rather than a 406 Not Acceptable) but sent them a text/html document! [2] I'm not sure from the HTTP/1.1 spec whether I've got the semantics of 307 correct, but it basically seems to be an alternative to 302 Found which unambiguously says repeat that request at this new URL, rather than 302 which in most browsers is implemented as Do a GET request on this new URL instead of whatever you were doing before. Legacy UAs don't understand the 307 code, but that's okay because only Yadis clients are going to find this response useful anyway. ___ general mailing list [EMAIL PROTECTED] http://openid.net/mailman/listinfo/general ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Key Discovery In DTP Draft 3
Hey guys, Was looking at http://openid.net/specs/openid-service-key-discovery-1_0-01.html tonight and curious why the decision was made to define the PublicKey / element which contains a link to the RSA key or X.509 certificate versus embedding the key in the XRDS file? From the research I've done tonight, it looks like the W3C in 2002 described how to do this as part of xmldsig. Seems like we can just use the KeyInfo element. http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-KeyInfo They've also then recently put out a note describing the changes to that document to match XML in 2006. http://www.w3.org/TR/2006/NOTE-DSig-usage-20061220/ Is there something that I'm missing from the design standpoint as to why this wasn't done? If anything, it seems like it would reduce a fetch if the key was in the XRDS file itself. --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Key Discovery In DTP Draft 3
Oooh, interesting... So looking at working draft 10 http://www.oasis-open.org/committees/download.php/17293 it seems that 3.2.5 is most relevant in that it describes xrd:XRD/xrd:Service/ds:KeyInfo which seems to be where in the schema the key would want to sit. The only thing is that 3.2.5 is talking about having the key present to verify a signature on the XRD file itself, though in this case it may not actually be signed. What I was toying with was something along the lines of: Service Typehttp://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-KeyInfo/ Type ds:KeyInfo ... /ds:KeyInfo /Service Thus it makes it easy for existing Yadis libraries to pick the key out by the Type element. --David -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Thursday, January 04, 2007 10:23 PM To: Recordon, David; 'Carl Howells'; 'Grant Monroe' Cc: specs@openid.net Subject: RE: Key Discovery In DTP Draft 3 Just FYI, the xmldsig KeyInfo element is already part of the XRD schema because the XRI Resolution spec uses it in the SAML form of trusted XRI resolution. And either the SAML form or the HTTPS form of XRI trusted res can give you the security characteristics in the Key Discovery spec. That said, there can be advantages to managing the cert via an independent service. So I'm not coming down on either side (yet ;-) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Thursday, January 04, 2007 10:07 PM To: Carl Howells; Grant Monroe Cc: specs@openid.net Subject: Key Discovery In DTP Draft 3 Hey guys, Was looking at http://openid.net/specs/openid-service-key-discovery-1_0-01.html tonight and curious why the decision was made to define the PublicKey / element which contains a link to the RSA key or X.509 certificate versus embedding the key in the XRDS file? From the research I've done tonight, it looks like the W3C in 2002 described how to do this as part of xmldsig. Seems like we can just use the KeyInfo element. http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-KeyInfo They've also then recently put out a note describing the changes to that document to match XML in 2006. http://www.w3.org/TR/2006/NOTE-DSig-usage-20061220/ Is there something that I'm missing from the design standpoint as to why this wasn't done? If anything, it seems like it would reduce a fetch if the key was in the XRDS file itself. --David ___ 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: SREG in Yadis
So I'm trying to word this and it seems each extension mentions it slightly differently. Looking at the following, thoughts are appreciated. section title='Discovery' tIt is RECOMMENDED that OpenID Provider support of this extension be advertised within the XRDS document, described in xref target='OpenIDAuthentication2.0' /, when working with all versions of OpenID Authentication. When doing so, the value of the lt;xrd:Typegt; element MUST be http://openid.net/extensions/sreg/1.1;./t /section --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Wednesday, January 03, 2007 9:45 PM To: specs@openid.net Subject: SREG in Yadis Seems the 1.0 SREG spec doesn't mention advertising support in your Yadis file. With the 1.1 draft, seems like this should be mentioned. Anyone against the Type being http://openid.net/extensions/sreg/1.1; which is what the proposed openid.ns.sreg field value is? http://openid.net/specs/openid-simple-registration-extension-1_1-01.html --David ___ 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: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman anOpenID?
My guess is that when a normal HTTP fetch is performed against http://xri.net/=bobwyman, the proxy resolver expects you to be in a browser and thus issues a 302 Redirect to your contact page. One option is if the iBrokers (is it iBroker or i-broker?) included Yadis on each contact page. This would mean the OpenID Relying Party would fetch http://xri.net/=bobwyman, be redirected to http://2idi.com/contact/=bobwyman, and then have that URL to perform discovery. The problem this presents is that the Relying Party follows redirects and canonicalizes the final URL as the Claimed Identifier. This thus means you'd no longer be making a claim about http://xri.net/=bobwyman, but rather that you own http://2idi.com/contact/=bobwyman. Thus if you change iBrokers, this assertion would no longer remain valid. It also removes the protection the iNumber (and CanonicalID tag) adds to the XRI Resolution process since i-names can be reassigned. I'm unsure if there is some trickery that could be done in the Yadis discovery document to resolve this, though really what I think would end up is you would enter http://xri.net/=bobwyman to start the discovery process, but then end up making an assertion about =bobwyman and not the URL version of it. Someone correct me here if my logic is wrong. --David From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Wyman Sent: Wednesday, January 03, 2007 8:44 PM To: openid-general Subject: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman anOpenID? My apologies if this is a really dumb question... Why is it that I can do OpenID authentication with either of =bobwyman or xri://=bobwyman but, according to the OpenIDEnabled checkup http://www.openidenabled.com/resources/openid-test/checkup/start?openid _url=http%253A%252F%252Fxri.net%252F%253Dbobwyman page, http://xri.net/=bobwyman is not a working OpenID? bob wyman ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
SREG in Yadis
Seems the 1.0 SREG spec doesn't mention advertising support in your Yadis file. With the 1.1 draft, seems like this should be mentioned. Anyone against the Type being http://openid.net/extensions/sreg/1.1; which is what the proposed openid.ns.sreg field value is? http://openid.net/specs/openid-simple-registration-extension-1_1-01.html --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Questions on Protocol
That sounds great to me! I like the model of starting here and growing as needed. :) --David From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Tuesday, January 02, 2007 10:12 AM To: McGovern, James F ((HTSC, IT)) Cc: specs@openid.net Subject: Re: Questions on Protocol Welcome, James. For my part, I know for sure that authorization comes up fairly regularly in the context of OpenID, so it's great you are stepping up to help us all find some answers! I would suggest that we start this work here, and if there is too much traffic, we move it off to a new list. On Jan 2, 2007, at 8:57, McGovern, James F ((HTSC, IT)) wrote: Johannes invited me to lead the development of the specification for including relationships and authorization as part of OpenID. I have the following questions: 1. Would it be too distracting to have the conversation occur on this listserv or should the admin establish another one? 2. I would also like to get a dialog going around how OpenID would need to work in order to support notions such as Identity propagation, integration into BPM and ECM platforms and support for Identity Based Encryption * 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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Consistency of negative responses to checkid_immediate requests
I think using cancel would add consistency between the modes, any reason I'm not seeing why it is a bad choice? --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Tuesday, December 26, 2006 4:17 PM To: Johnny Bufu Cc: Martin Atkins; specs@openid.net Subject: Re: Consistency of negative responses to checkid_immediate requests Reviving an old thread... On 12/14/06, Johnny Bufu [EMAIL PROTECTED] wrote: On 14-Dec-06, at 12:13 AM, Josh Hoyt wrote: On 12/13/06, Martin Atkins [EMAIL PROTECTED] wrote: Josh Hoyt wrote: It's confusing to me make the failure response to an immediate mode request be id_res, especially if that is not the failure response for setup mode. I can't see a reason that they can't both use the cancel response to indicate that the OP or end user do not wish to complete the transaction. This is a very minor change, but it will make the spec simpler. I think the RP will want to do something different in these two cases. That's true, but the RP will probably need to handle the success case differently for immediate mode anyway (e.g. it will have to do AJAX to update the page) so I expect it to have a specific return_to URL for immediate requests. Since using a different return_to is trivial, I prefer the consistency of negative responses. The current / v1 modes will need to be mentioned in the compatibility section, and also implemented. Not sure if this simplification will then still be worth. Since the user_setup_url parameter is now gone, there is no way to differentiate between a broken/truncated response and a cancel response to an immediate mode request. I think that there needs to be *some* positive way to identify cancellation of immediate mode requests, rather than depending on lack of other parameters. I'd be happy with any of these ways to positively identify a cancel response to checkid_immediate: 1. re-using cancel as I suggested above 2. introducing a new mode (e.g. setup_needed ) 3. adding a parameter that the id_res response is an immediate cancellation (e.g. openid.setup_needed=true) I no longer buy the argument about having to support the OpenID 1 mechanism in the library, since cancellation of an immediate mode response is already indicated differently between OpenID 1 and 2, so it's really just a matter of what goes into the OpenID 2 code path rather than whether the two code paths exist. Pseudo-code for the current approach: def isSetupNeeded(): if this is OpenID 1: return whether there is a user_setup_url parameter if this is OpenID 2: # This is the branch that I want to change return whether there are any other OpenID parameters passed at all Thoughts? Josh ___ 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: OpenID Exchange
Awesome, glad to see this! Would be great as Johannes said to see some flow examples and how you'd see it integrate to do something like exchange profile data or post a photo on your blog. Would love to see this formalized and happy to help however I can! --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Wednesday, December 13, 2006 4:44 AM To: specs@openid.net Subject: OpenID Exchange I have made an early draft of a spec called OpenID Exchange on the wiki: http://openid.net/wiki/index.php/OpenID_Exchange_1.0 The goal of this protocol is to allow user-accompanied HTTP requests. user-accompanied means that a consumer makes a request to a service on behalf of a user and the user reviews and approves the request. Example applications of this include: * Zooomr posting photos into your blog with your one-time approval, without disclosing your login credentials. [1] * Fetching of user profile information. * Social networking friendship handshakes. [2] The protocol should, in theory, be able to act as a transport for any HTTP-based protocol such as SOAP and AtomAPI, as well as for simple GET requests. The protocol for post in my blog could, for example, just be an AtomAPI POST request made over OpenID Exchange. This is still work-in-progress. The spec needs lots of refinement and at some point I'll have to make a demo or two. [1] You can still see the results of the demo of my earlier version of this on LiveJournal, albeit without the pictures: http://openrpcdemo.livejournal.com/ [2] Discussed further in my blog entry on social networking: http://www.apparently.me.uk/623.html ___ 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: OpenID IPR Policy Draft
Brett, We certainly are going to be working with our counsel, though first wanted to make sure we captured the community's intent. --David -Original Message- From: Brett McDowell [mailto:[EMAIL PROTECTED] Sent: Thursday, December 07, 2006 06:47 AM Pacific Standard Time To: Recordon, David Cc: [EMAIL PROTECTED]; specs@openid.net Subject:Re: OpenID IPR Policy Draft This is normally lawyer work. I recommend the companies individuals invested in OpenID immediately turn this exercise over to your legal counsel to ensure your interests--and the interests of the community--are protected appropriately. Does the new OpenID organization have legal counsel retained (I don't mean volunteers, but actually hired)? If not, that would be my second recommendation. --Brett On 12/6/06, Recordon, David [EMAIL PROTECTED] wrote: Hey guys, Been working with Gabe, and others, on starting to draft an IPR Policy for OpenID specifications. We'd appreciate feedback in terms of if what is written captures the correct intent of the community? We realize the language isn't technically as tight as it needs to be, though first want to make sure it is saying the right thing. It is largely based on the IPR Policy for Microformats. http://openid.net/wiki/index.php/IPR_Policy http://openid.net/wiki/index.php/IPR_Policy Thanks, --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs http://openid.net/mailman/listinfo/specs -- Brett McDowell +1.413.662.2744 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID IPR Policy Draft
Hey guys, Been working with Gabe, and others, on starting to draft an IPR Policy for OpenID specifications. We'd appreciate feedback in terms of if what is written captures the correct intent of the community? We realize the language isn't technically as tight as it needs to be, though first want to make sure it is saying the right thing. It is largely based on the IPR Policy for Microformats. http://openid.net/wiki/index.php/IPR_Policy Thanks, --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: OpenID Simple Registration 1.1 - Draft 1
Done, commit 172. --David -Original Message- From: Jonathan Daugherty [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 06, 2006 1:41 PM To: Recordon, David Cc: specs@openid.net Subject: Re: OpenID Simple Registration 1.1 - Draft 1 # Please review and +1 or -1 for final draft. Only change is adding # namespace parameters to request and response to work as a 2.0 # extension. It also doesn't hurt to have these parameters in 1.1 # messages. +1, but please change my email address in the authors list to [EMAIL PROTECTED] Thanks, -- Jonathan Daugherty JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Re: [OpenID] OpenID Assertion Quality Extension - Draft
Yeah, we looked at this a bit when drafting the extension originally. There are just so many factors that go into password choice/enforcement that describing them becomes quite difficult. It also is possible to describe features which actually are just red herrings. I wish it was simpler so something could be included. :-\ Also pulling general@ off this thread. --David -Original Message- From: Avery Glasser [mailto:[EMAIL PROTECTED] Sent: Saturday, December 02, 2006 8:35 PM To: [EMAIL PROTECTED] Cc: Recordon, David; specs@openid.net; [EMAIL PROTECTED] Subject: RE: Re: [OpenID] OpenID Assertion Quality Extension - Draft Daniel, It's not a bad idea, but it doesn't actually drive any more knowledge about the security of the authentication. There are so many factors when calculating the entropy and overall security of a password that I don't think it should be included in the AQE. Listing the password length, the criteria for the password, how long since last password change and other factors should probably be either part of the Attribute Exchange or the eventual convergence/alignment with SAML AC. - Avery It might be useful to some RP's to know of any complexity schemes put on users' passwords. How about: password.min_length=8 password.max_length=16 the number of characters that the password is between. password.max_length would probably be more useful as I don't see many RP's complaining if the OP allows for long passwords. I can see the RP wanting my password to be at least for characters though. password.complexity=alphanumeric,mixed-case a comma separated list of common restrictions to the password's format. Some possible values: none, numeric, alpha, alphanumeric, lower-case, upper-case, mixed-case, non-dictionary, case-insensitive none or omitting one of the facets would have the effect of allowing alphanumeric characters of any case + possible some special characters. case sensitive. What do you think? Daniel E. Renfer http://kronkltd.net/ On 12/1/06, Avery Glasser [EMAIL PROTECTED] wrote: All, Attached is the new XML for draft 2 of the AQE spec. It has been checked into SVN as release 140. David, Can you convert it to HTML and repost it to the list? -- Avery == Avery Glasser CTO VxV Solutions, Inc. + 1.415.992.7264 - office + 1.415.290.1400 - mobile + 1.415.651.9218 - fax 329 Bryant Street, Suite 2D San Francisco, CA 94107 email: [EMAIL PROTECTED] i-name: =avery == This e-mail (including any attachments), is confidential and intended only for the use of the addressee(s). It may contain information covered by legal, professional or other privilege. If you are not an addressee, please inform the sender immediately and destroy this e-mail. Do not copy, forward, use or disclose this e-mail. Thank you. -- == Avery Glasser VxV Solutions, Inc. + 1.415.992.7264 - office + 1.415.290.1400 - mobile + 1.415.651.9218 - fax 329 Bryant Street, Suite 2D San Francisco, CA 94107 == This e-mail (including any attachments), is confidential and intended only for the use of the addressee(s). It may contain information covered by legal, professional or other privilege. If you are not an addressee, please inform the sender immediately and destroy this e-mail. Do not copy, forward, use or disclose this e-mail. Thank you. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: OpenID Assertion Quality Extension - Draft
Sorry for the spam, uploaded so now have perma-links and am calling it Draft 1 since it is the first public draft: http://openid.net/specs/openid-assertion-quality-extension-1_0-01.html http://openid.net/specs/openid-assertion-quality-extension-1_0-01.txt --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Wednesday, November 29, 2006 9:46 AM To: specs@openid.net Cc: [EMAIL PROTECTED] Subject: OpenID Assertion Quality Extension - Draft So this is the first public draft of the extension that Avery, Paul, and I have been working on the past two weeks. Definitely looking for feedback about all aspects of it and it still has some gaps, though we wanted to put it out there for comments. Thanks, --David Abstract: This extension to the OpenID Authentication protocol provides means for a Relying Party to request additional information about the specifics by which a user enrolled and/or authenticated to the OpenID Provider, as well as for an OpenID Provider to add such information into assertions. Such information may be necessary for use cases in which, for an RP to make an assessment of the quality of an assertion from a OP, the OP's identity is not on its alone sufficient (as might be the case were an OP capable of authenticating a user through various authentication mechanisms). While there are other aspects of lifecycle management that may bear on the resultant quality of an OpenID Authentication assertion - enrollment and authentication are generally the two characteristics that are most useful in distinguishing authentication quality. Consequently, we focus on these aspects here. We expect that other aspects (e.g. security characteristics, credential provisioning, etc) could be dealt with in the future. As an extension, it requires no changes to either the Yadis protocol or the OpenID Authentication protocol and is viewed as an optional extension though its use is certainly recommended. We acknowledge that, while none of the information expressed via this extension can be verified by the Relying Party in a technological fashion, this need not be viewed as an issue. The lack of an inherent trust model within OpenID allows for Relying Parties to decide which OPs they trust using whatever criteria they choose - likewise RPs will decide whether or not to trust claims as to authentication quality from such OPs as well. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OP Identifier vs. OP-Specific Identifier
So I'm working on cleaning up the terminology section with edits from Drummond. On first read I had no idea what the difference between OP Identifier and OP-Specific Identifier were. Now that my brain has kicked in I do, but I have the feeling this is going to be really confusing for others reading the specification. I really think we need to get our terminology down, since right now it is honestly quite confusing: - Identifier (umbrella definition) - Claimed Identifier (umbrella definition) - OP-Specific Identifier (needs context) - OP Identifier (needs context) - Public Identifier (tries to create context) - Private Identifier (tries to create context) - Privacy-protected login (have we even defined this) How can we clean this up? I think the problem is that we're trying to describe features via the terminology section. --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Map/Normalize Email Address to IdP/OP URL (Was [PROPOSAL] Handlehttp://[EMAIL PROTECTED] Style Identifiers)
I'm not sure if it would necessarily be thrown away, I guess it is really up to the IdP. With two identifiers, it is pretty easy to pass to the IdP and let it decide what it wants to do. 1) I enter [EMAIL PROTECTED] as my identifier on the RP 2) RP does discovery on recordon.name and finds my IdP 3) RP constructs authentication request with openid.disco_id being [EMAIL PROTECTED] and openid.identifier being http://openid.net/identifier_select/2.0; That was all I was looking for describing in my initial proposal. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rowan Kerr Sent: Friday, November 10, 2006 11:23 AM To: specs@openid.net Subject: Re: Map/Normalize Email Address to IdP/OP URL (Was [PROPOSAL] Handlehttp://[EMAIL PROTECTED] Style Identifiers) On 11/9/06, David Fuelling [EMAIL PROTECTED] wrote: So, '[EMAIL PROTECTED]' would be treated as if the User had entered 'http://any.edu' (the URL of their IdP/OP) into the OpenId login form. I don't like the idea of telling people to enter their username, and then throwing it away. As mentioned below, [EMAIL PROTECTED] can map to a valid http url. This really, I suppose, is a matter of choice on the part of an IdP as to what sorts of instructions they give to their users about identifying themselves to RPs. Verisign's PIP does userx.pip.verisign.com Somone might do example.com/user/x Someone else might do [EMAIL PROTECTED] Discovery would be performed identically on all the above ... and we're left with a problem of user education. -Rowan ___ 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: OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP)
Hey Adam, Thanks for the insight! I know, as Dick described, there was a design decision made in terms of enabling payloads larger than 2Kb within OpenID Authentication requests and responses. With that said, there are other approaches, such as using GET requests and including a token to retrieve more data via OpenID DTP as a back-channel request. So lots to think about... --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Nelson Sent: Sunday, November 12, 2006 5:25 PM To: specs@openid.net Subject: OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP) I've been tracking OpenID auth from 1.0 with great interest. Last summer Johannes Ernst explained to me how it was that one might use openid to authenticate a non-interactive user agent such as a REST API consumer by intercepting the RP's redirect and providing the info from the IdP itself. Given OpenID's design goals (decentralized, lightweight, flexible identity management), and its seemingly inevitable adoption into the mashup-minded web 2.0 ecosystem (God help me I'm buzzwording!), it seems to me that OpenID's value is significantly enhanced if the identities it enables can be used to authenticate to SOAP and REST APIs as well as interactive web sites. Having said that, I was surprised to note in draft 10 of OpenID Auth 2.0 that the HTTP redirect method of communication between the RP and the IdP is deprecated in favor of an HTML forms-based approach. This suggests to me that OpenID Auth 2.0 is not compatible with REST or SOAP or any other binding that doesn't involve the exchange, parsing, and submission of HTML forms. I'm curious why this decision was made, and if its implications have been fully considered. Has there been any thought given to an alternative means of authentication, perhaps via custom HTTP headers or some other non-HTML means? If not, does this mean OpenID is not intended to support authentication to programmatic APIs? Thanks, Adam ___ 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: Went Through it With Brad
Solution 1 seems like the most simple. openid2 is a bit ugly, but does resolve the problem. Otherwise we'd have to do something like Yadis discovery against the server endpoint which would make things more complicated and meta. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Monday, November 13, 2006 4:15 PM To: Recordon, David Cc: specs@openid.net Subject: Re: Went Through it With Brad On 11/8/06, Recordon, David [EMAIL PROTECTED] wrote: 2) 7.3.3 basically deprecates HTML-based discovery, saying that it is a way to know that the IdP is using Auth 1.1. While I know we believe Yadis will be used in most applications, I hypothesize that the simplicity of HTML-based discovery will have it continue to prevail. I thus would propose we remove the sentence saying that this is a way to know that an IdP is running version 1.1. Yeah, it does. The justification for this is that there is no way to specify a version for the server, so we have to assume something, and since HTML discovery already used in 1.1, that's the only reasonable assumption to make. I see two ways out of this: 1. Add another rel value to the HTML discovery for OpenID 2: link rel=openid.server openid2.server href=... 2. Add some way of doing discovery on the endpoint URL for determining the version, so it doesn't have to be part of the user's XRDS or HTML document Either one of these would let us keep the nice, simple HTML discovery mechanism for 2.0. Thoughts or ideas? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: OpenID.net Service Type Namespaces
Yeah, that is my concern. Much easier to manage the namespace if this part is separate, then no matter what software is run for openid.net anytime down the road we won't have issues. --David -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 11:56 AM To: 'Dick Hardt'; Recordon, David Cc: specs@openid.net Subject: RE: OpenID.net Service Type Namespaces My understanding is that the concern is with potential conflicts in the actual functioning of openid.net. Creating a clean DNS namespace for specs at specs.openid.net does seem like a good solution to me. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Tuesday, November 07, 2006 8:09 AM To: Recordon, David Cc: specs@openid.net Subject: Re: OpenID.net Service Type Namespaces What is the concern? The argument for keeping it the current way is for consistency. The URL resolution does not need to be trusted does it? On 6-Nov-06, at 5:04 PM, Recordon, David wrote: I'm still concerned with using the openid.net/ namespace. Objections to using http://specs.openid.net/authentication/2.0/signon? We don't need to change this in legacy stuff, just for 2.0 moving forward. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Saturday, October 21, 2006 7:34 PM To: Granqvist, Hans Cc: Recordon, David; specs@openid.net Subject: Re: OpenID.net Service Type Namespaces I am very supportive of an HTTP GET retrieving the specification. I think there are some issues with putting the date in the URL: 1) the URL is unknown until the spec is completed. Any implementations being done during the specification then have a moving target. The URL is embedded in the Yadis document and I can see it causing some headaches for people that it is not fixed until the end. 2) the grouping is by time instead of by specification. If I want to see all versions of a specification, it is not obvious Currently we have: http://openid.net/signon/1.0 http://openid.net/signon/1.1 http://openid.net/server/2.0 http://openid.net/signon/2.0 http://openid.net/identifier_select/2.0 Given that the 1.x ones are already there, I would recommend we keep using that scheme. -- Dick On 20-Oct-06, at 3:39 PM, Granqvist, Hans wrote: It has had some voices against it, but how about considering this template (used in for example W3C xmldsig and xmlenc): http://openid.net/[year]/[month]/[project]#[type] Time-dependent (rather than version--dependent) namespaces can evolve freely and will not be tied down to specific versioning numbers. Example: http://openid.net/2006/10/authentication http://openid.net/2006/10/authentication#signon It's cool if an HTTP GET on these links returns the specification. Once a spec is finalized, the then current year/month becomes that spec's namespace. For example, xmlenc's namespace is http://www.w3.org/2001/04/xmlenc Hans -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Friday, October 20, 2006 3:09 PM To: specs@openid.net Subject: OpenID.net Service Type Namespaces Right now we have things like http://openid.net/signon/1.1, http://openid.net/sreg/1.0, etc. This doesn't really seem to scale, populating the main http://openid.net namespace. Could we do something like http://specs.openid.net/authentication/2.0/signon or http://specs.openid.net/authentication/2.0/identifier_select as well as then http://specs.openid.net/sreg/1.0? This would give all the specs their own namespaces, as well as make it so we can do smart redirection from each of these type urls to the correct anchor in the individual spec. --David ___ 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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: IdP's Advertising Both http and https
Moving this to the list, I really should have started it there in the first place. --David -Original Message- From: Recordon, David Sent: Monday, November 06, 2006 2:06 PM To: 'Dick Hardt'; Josh Hoyt Subject: RE: IdP's Advertising Both http and https Hey Dick, But the security warnings will still exist: - RP redirects me to http on IdP - IdP redirects me to https on IdP for login page (warning) - I interact with IdP for trust request via https - I submit HTTPS form - IdP redirects me back to RP via http (warning) Am I missing something here? The only way to remove all of the warnings is adding additional redirects to itself in these steps to remove the warnings. I guess I'm not sure what I think we should do, though don't think this is a simple problem. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Saturday, November 04, 2006 6:49 PM To: Recordon, David Cc: Josh Hoyt Subject: Re: IdP's Advertising Both http and https Hi David If the RP is only using HTTP, then then the request and response are in the clear between the RP and user-agent, and using SSL between the user-agent and OP has nominal benefit. In case it was not clear, the OP SHOULD switch to HTTPS for all other transactions between the user- agent and the OP, so user authentication is secure and any other personal data transported while the user is deciding what to do is secure. I think many RPs will only be using HTTP, so this will be a usability issue if they are seeing the browser warning. ... but perhaps I am not clear on what you were thinking you wanted to do? -- Dick On 30-Oct-06, at 4:55 PM, Recordon, David wrote: So I was writing this one up for the notes and it just doesn't seem to be sitting well with me as I think about it more: - An IdP can already advertise both http and https endpoints in their Yadis files. A RP should use the same schema when redirecting the user to the IdP as it uses for its endpoints, though if this is not possible can decide to not continue the transaction. This is desired due to browsers showing a security warning when redirecting from https to http and vice-versa. So if the RP is HTTP, I think the security benefits of using SSL for the request (if the IdP offers a https endpoint) outweigh the fact that the user will be shown a warning on the response. I guess I have a hard time making this recommendation when instead I personally would recommend an IdP not advertise a HTTP endpoint if it has a HTTPS one. I think the reality is that anyone doing anything but testing with OpenID really should be using SSL, though certainly also don't believe that 100% of IdPs and RPs will do so. Thoughts? --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: OpenID Authentication 2.0 Pre-Draft 11 (Take 2)
Thanks! I remember you mentioning that before though I missed it. Revision 93 corrects it. Thanks, --David -Original Message- From: Johannes Berg [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 2:07 PM To: Recordon, David Subject: Re: OpenID Authentication 2.0 Pre-Draft 11 (Take 2) On Tue, 2006-11-07 at 12:31 -0800, Recordon, David wrote: (codepoint 10, /n) Maybe I shouldn't even be pointing this out but I think \n was intended here? johannes ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Making return_to Optional
From the call last week and the proposal at http://openid.net/pipermail/specs/2006-October/000430.html, return_to is not an optional parameter in the authentication request. The idea being that a RP not sending it signals the IdP to not redirect the user back; rather an extension will be doing something useful. I've checked in this change, though would like it reviewed since I am not completely happy with all the wording. http://openid.net/svn/comp.php?repname=specificationspath=compare%5B%5 [EMAIL PROTECTED]compare [EMAIL PROTECTED]ma nualorder=1 Thanks, --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
IdP vs OP (WAS: RE: Editors Conference Call)
I see both sides of this discussion. I think John is correct that the role of an OP really is not that different than that of SAML's IdP. The difference comes down to the trust model. I certainly think reputation networks will exist which rate OPs, RPs, users, etc and will ultimately be needed for a technologies with promiscuous trust models to thrive in a large scale. I guess reading more of this is making me question if renaming IdP really is the best thing to do in OpenID. I think if anything we all, as a larger community, should be working to bring OpenID and SAML closer together versus driving them further apart. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Wednesday, November 01, 2006 2:20 PM To: John Kemp Cc: specs@openid.net Subject: Re: Editors Conference Call On 1-Nov-06, at 12:28 PM, John Kemp wrote: OK. Just checking. So an IdP/OP can choose whether or not to trust a particular RP, based on some out-of-ban criteria. And an RP can choose whether or not to trust the assertions of a particular IdP/OP? OK good. Technically possible, yes for the RP to decide on an IdP/OP. Currently, there is no verified RP identity, so the IdP/OP cannot make that decision. I have not had a chance to wade into that discussion. I'd highly recommend it when you get the chance. in my queue :) I suspect the latter case will be unlikely, if OpenID is to be successful. And I do not. And that is the big driver why it should be OP instead of IdP. I think what you're trying to say is that OpenID won't depend on static trust relationships (like business contracts) between RPs and IdP/ OPs - is that right? In which case, sure, I get that. But I do think OpenID will depend on there emerging a way of some RP trusting (or not) some IdP (and vice-versa). Whitelists and blacklists seem like a scalable and dynamic way of doing that, and would seem to be a reasonable way of minimizing the presence of rogue IdPs. Don't take my word for it though - look at the discussion on [EMAIL PROTECTED] I don't think there should be an OP reputation. I will wade into the security@ list to discuss. asserted data. The OP is not verifying the accuracy of any of the attributes in attribute exchange. A claim by my IdP/OP /might/ be a claim by a third-party, no? And if the IdP/OP makes such a claim on my behalf (and is not under my direct control), won't it at least want to verify that the subject of the claim is also the user whose identifier it asserted in OpenID Authentication? If the OP is making a separate claim about you, then it is not being an OP at that time. Perhaps I am missing your point here though. In OpenID Authentication, there is no trust relationship requirement between the IdP and RP., and the only thing the IdP asserts is a binding between the user and an identifier (OpenID URL or i-name). And on what basis does the OP assert this binding to an RP? Doesn't the OP typically authenticate that binding, or does it simply take the users identifier on blind faith, and assert away? The OP authenticates the user (how the OP authenticates the user is out of scope of the spec). OK - so the user probably maintains an account with the OP, very much like a user would with an IdP? Unless the user runs her own OP. The OP has a mechanism to determine which user it is interacting with. If the user is running her own OP, then there is still an authentication process of some kind such as access to the machine. -- 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: Making return_to Optional
Yep... -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Monday, November 06, 2006 7:54 PM To: Recordon, David; specs@openid.net Subject: RE: Making return_to Optional David, in the message below, I assume you meant to say return_to is NOW an optional parameter... instead of return_to is NOT an optional parameter That's the only way I can make sense of it. Am I right? =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Monday, November 06, 2006 11:10 AM To: specs@openid.net Subject: Making return_to Optional From the call last week and the proposal at http://openid.net/pipermail/specs/2006-October/000430.html, return_to is not an optional parameter in the authentication request. The idea being that a RP not sending it signals the IdP to not redirect the user back; rather an extension will be doing something useful. I've checked in this change, though would like it reviewed since I am not completely happy with all the wording. http://openid.net/svn/comp.php?repname=specificationspath=compare%5B%5 [EMAIL PROTECTED]compare [EMAIL PROTECTED]ma nualorder=1 Thanks, --David ___ 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: Making identities persistent?
Pete, While the transaction with the IdP is about the derived identifier (sort of like that term actually), the RP uses the delegated identifier when referencing the user. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete Rowley Sent: Wednesday, November 01, 2006 10:53 AM To: Rowan Kerr Cc: specs@openid.net Subject: Re: Making identities persistent? Rowan Kerr wrote: On Wed, 2006-11-01 at 11:33 -0500, John Kemp wrote: 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. Isn't this was already covered in the spec? You accomplish this by creating an HTML page on some website you control with a http-equiv meta tag in it that points to your IdP. Then you use your own url as your Identity, even though ultimately the data is pulled from the IdP. So if you ever want to change IdP's you simply update your html page with the new server. And your Identifier never needs to change. Except that the spec specifies that it is the derived identifier of the IdP that is used at the RP - which means a delegated identifier actually isn't used as an identifier. That is not quite the same thing. -- Pete ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Editors Conference Call
This morning Dick, Josh, and I got on Skype for 2.5 hours to try and hash through all the remaining proposals. Unfortunately Brad couldn't join us, though I did talk to him about some of this stuff as well beforehand. - Authentication Age will be developed as an extension due to questions around what is the best way for it to work, what features does it need, etc - The field setup_url will be removed from a checkid_immediate response, rather the RP should fallback to a checkid_setup request to complete the transaction. It has been found that in the, albeit few, implementations of checkid_immediate this is the behavior for the setup_url anyway. - Support bare requests by having the field openid.return_to as optional in checkid_* requests. There is a worry of user's not knowing when they'll be redirected back and when they won't, though that will only be worked out by allowing this functionality. - Clarify that the openid.realm parameter should be used to uniquely identifier relying parties - There are some places where it could be clear in step-by-step instructions of what an IdP needs to do in various parts of the protocol, like is done in section 12 for rp's. Sxip will provide pointers to where this clarity can be added. - Rename Identity Provider to OpenID Provider (IdP - OP) to add clarity to the term since IdP has a very different meaning in the SAML and WS-* worlds - The spec won't speak to what a RP should do if it has an identifier like [EMAIL PROTECTED], worried about setting a confusing precedent of allowing this form of identifier for discovery. Users are used to entering, example.com in their URL bar to goto the site, so entering the same to login doesn't seem like to far of a stretch. All of OpenID has a user education challenge and this doesn't seem very different. - Spec will say in essence, RP's SHOULD give the text field a user enters their OpenID Identifier a name attribute with a value of 'openid_identifier', though if a RP wishes to support rich clients it MUST do so. - Dick will be writing a separate document discussing how RPs can advertise services, logos, etc - There cannot be parameters with the same name, make sure spec says this, we think it does. - Josh will be updating his delegation proposal patch to specify two identifiers for all transactions. This will create a consistent paradigm when dealing with delegation or when not. Goal is to have all of these changes made by end of day Wednesday. I doubt I've added enough detail in all places, so feel free to ask for clarifications or wait to comment on the next draft. --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [security] [PROPOSAL] Adding More Color Around SSL Use
This has now been checked in. http://openid.net/svn/listing.php?repname=specificationspath=%2Frev=73 sc=1 --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Thursday, October 26, 2006 1:48 PM To: [EMAIL PROTECTED]; specs@openid.net Cc: Martin Atkins Subject: [security] [PROPOSAL] Adding More Color Around SSL Use I'm planning to check in the following patch to the authentication spec later today unless anyone has STRONG objections. It says that SSL is not REQUIRED, though comes as close to saying that it is that I think we can. Josh, Mart, and I believe this is a good middle position to take on the matter. We certainly believe any reputable IdP will correctly use SSL, though there are cases (such as using OpenID Authentication fully within your own trusted network) where it is not required. --David Index: openid-authentication.xml === --- openid-authentication.xml (revision 68) +++ openid-authentication.xml (working copy) @@ -2216,7 +2216,17 @@ t In order to get protection from SSL, SSL must be used for all parts of the interaction, including interaction with -the End User through the User Agent. +the End User through the User Agent. While the protocol + does not require SSL be used, its use is strongly + RECOMMENDED. Current best practicies dictate that an IdP + SHOULD use SSL, with a certificate signed by a trusted + authority, to secure its service endpoint. In addition, + SSL, with a certificate signed by a trusted authority, + SHOULD be used so that a Relying Party can fetch the + End User's URL in a secure manner. Please keep in mind + that a Relying Party MAY decide to not complete, or even + begin, a transaction if SSL is not being correctly used + at these various endpoints. /t /section /section ___ security mailing list [EMAIL PROTECTED] http://openid.net/mailman/listinfo/security ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
[PROPOSAL] Adding More Color Around SSL Use
I'm planning to check in the following patch to the authentication spec later today unless anyone has STRONG objections. It says that SSL is not REQUIRED, though comes as close to saying that it is that I think we can. Josh, Mart, and I believe this is a good middle position to take on the matter. We certainly believe any reputable IdP will correctly use SSL, though there are cases (such as using OpenID Authentication fully within your own trusted network) where it is not required. --David Index: openid-authentication.xml === --- openid-authentication.xml (revision 68) +++ openid-authentication.xml (working copy) @@ -2216,7 +2216,17 @@ t In order to get protection from SSL, SSL must be used for all parts of the interaction, including interaction with -the End User through the User Agent. +the End User through the User Agent. While the protocol + does not require SSL be used, its use is strongly + RECOMMENDED. Current best practicies dictate that an IdP + SHOULD use SSL, with a certificate signed by a trusted + authority, to secure its service endpoint. In addition, + SSL, with a certificate signed by a trusted authority, + SHOULD be used so that a Relying Party can fetch the + End User's URL in a secure manner. Please keep in mind + that a Relying Party MAY decide to not complete, or even + begin, a transaction if SSL is not being correctly used + at these various endpoints. /t /section /section ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Yet Another Delegation Thread
What I wrote up doesn't allow a RP to have the information it needs to maintain state is my understanding. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 24, 2006 5:12 PM To: Recordon, David Cc: specs@openid.net Subject: Re: Yet Another Delegation Thread Can we have those conversations on the list so that everyone understands what the goals missed are? I'd appreciate feedback on the revised proposal I emailed out and what is missing from it. -- Dick On 24-Oct-06, at 3:45 PM, Recordon, David wrote: I honestly wasn't really putting it out as a proposal, rather describing more of the different cases involved in all of this. In any case, talking this over more with Josh and Drummond it doesn't actually accomplish all of the goals anyway. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Monday, October 23, 2006 11:04 PM To: Drummond Reed Cc: Recordon, David; specs@openid.net Subject: Re: Yet Another Delegation Thread +1 Glad to see that we have settled on one identifier parameter On 23-Oct-06, at 7:07 PM, Drummond Reed wrote: Here's another way to summarize the conclusions David and I reached in our analysis today: 1) In OpenID Authentication 1.1, if there is a difference between the identifier the user wants to assert to an RP and the identifier the IdP wants to assert for the user (lets just call them ID1 and ID2), then the mapping from ID1 to ID2 can only be handled by the RP (using the OpenID delegate feature). 2) Josh and Mart have argued that in OpenID Authentication 2.0 an IdP should also be able to handle the mapping between ID1 and ID2, and indeed in the directed identity use case, the IdP MUST handle this mapping. 3) What David and I realized today is that there are even use cases for BOTH the RP and IdP doing the mapping. In other words, even if an RP maps from ID1 to ID2 and passes ID2 to the IdP, there shouldn't be anything to prevent the IdP from mapping ID2 to ID3 and passing ID3 back to the RP (as long as the RP verifies the IdP is authoritative for ID3). Example: I log into RP using one URI#1, which maps in my XRDS document to another IdP- specific URI#2, and then when logging into my IdP it reminds me that I previously used URI#3 at this RP, so I choose URI#3. 4) Therefore, as long as the protocol: a) REQUIRES the RP to do the mapping from ID1 to ID2 if present in the HTML or XRDS (which gives the user IdP-independent mapping if the user wants it), and b) ALLOWS the IdP to do the mapping from whatever identifier it receives (ID1 or ID2) to whatever identifier it wants to assert on behalf of the user (ID3), then all use cases are supported. A user can take advantage of RP mapping, IdP mapping, or both. 5) This flexibility means that, with the rules David wrote, only one identifier parameter should be needed (although, as David suggests, a second parameter that is only a display hint from the RP to the IdP might be a help -- and I would argue that it could work in the other direction as well, but again only as a display hint.) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Monday, October 23, 2006 6:09 PM To: specs@openid.net Subject: Yet Another Delegation Thread So been going through all of this up in Seattle with Drummond and think I fully have my head around this. Thinking we have the following cases, which Draft 10 basically already addresses. In any of the responses, the IdP MAY return a differing value for openid.identity than the RP requested. This obviously has varying degrees of usefulness depending on the specific situation. See below for rules RP must follow to protect itself from bogus assertions. 1) IdP Registered a) Entered http://user.myidp.com (IdP implicitly knows it owns) URI - http://myidp.com/server.cgi Request openid.identity - http://user.myidp.com Response openid.identity - http://user.myidp.com b) Entered http://user.example.com (IdP has an out of band registration process where it verifies via discovery) URI - http://myidp.com/server.cgi Request openid.identity - http://user.example.com Response openid.identity - http://user.example.com 2) Delegated (IdP knows nothing about what the user entered) a) Entered http://user.example.com URI - http://myidp.com/server.cgi OpenID:Delegate - http://user.myidp.com (IdP Controlled) Request openid.identity - http://user.myidp.com Response openid.identity - http://user.myidp.com b) Entered =user.example (or @2idi for Directed Identity case) URI - http://myidp.com/server.cgi
RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
While I'd certainly agree that a goal is letting anyone setup and IdP and have it work on any RP, I see that as utopia. The protocol should certainly support that, as well as not do anything to actively thwart it. With that said, OpenID as a protocol can be used in cases where this may not be desired. I agree that the best way to look at this is by creating a distributed trust/reputation network. This thus allows a RP to intelligently make a decision of if it should accept a given identifier, or the IdP it is hosted on. Right now I see this as needed to really bootstrap large scale adoption. Any word from Karmasphere about something like this Meng? --David P.S. Plain-text kills all fonts. :) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kaliya Hamlin Sent: Sunday, October 22, 2006 3:43 PM To: specs@openid.net Subject: Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers For starters please don't use Comic Sans in professional correspondence. it is very hard to read (or take seriously) http://bancomicsans.com/home.html On Oct 22, 2006, at 11:44 AM, Praveen Alavilli wrote: It's more of a problem with how we can accept 3rd party OpenId users at AOL (we as an RP). Obviously for simple use cases like leaving comments on blogs it wouldn't really matter as long as the user is identified by someone (and someone doing rate limiting or something else to prevent spamming - otherwise I still can't see how it reduces spam anyway) - but when we want to take it to the next level - provide more services to these users (photos/calendar/etc.. ) we want to limit it to only a few IDPs whom we trust. (due to both security and business reasons). This doesn't really work in the model. The goal is to let anyone set up their own OpenID and that basically across the OpenID universe it works. You limiting it to only like verisign or other 'big' IdP's is not really part of the vision of what we are trying to build. Obviously behind this whole network needs to be reputation for IdPs and individual OpenID addresses. So this is the problem we are trying to figure out how we can message the users that we support OpenIds from certain providers (say Verisign PIP) but not from all. This is one way to approach it and I hope you don't do it this way because it breaks what OpenID is about. Another area where we want some more clarification (if it already exists) or support is about how we can have a persistent handler (apart from URI) for a given user so it would help in cases when a user's account gets reclaimed by someone else. ahh...that is where further reading of what i-names and i-numbers are about would help. Because there is another level of indirection built in, when an i-name is reassigned the i-number below it is not. This helps users not have the 'reclaiming by someone else problem' when depending on URLs. __ Identity Woman: Saving the world with user-centric identity. www.identitywoman.net ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Two Identifiers - no caching advantage
* Protocol has two distinct identifiers: public and IdP-local. Relying party manages delegation. IdP does not even know that the delegation has taken place and has no way to stop it happening [1]. RP now has to do more work, but identifier portability now comes for free. I'm much more in favor of that, though see the value in having the IdP know the public identifier so that it can correctly prompt the user. I think one identifier, with the IdP managing the entire relationship is too much of an architectural jump from 1.1. Take LiveJournal for example, somehow I doubt we'd see delegation support in this case anytime soon. I think what is important is keeping the simplicity of delegation in 1.1, while cleaning up the metaphor and making it more user-friendly at the same time. Perfection is the enemy of the good. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Sunday, October 22, 2006 1:34 PM To: specs@openid.net Subject: Re: Two Identifiers - no caching advantage Dick Hardt wrote: On 21-Oct-06, at 10:52 PM, Josh Hoyt wrote: On 10/21/06, Dick Hardt [EMAIL PROTECTED] wrote: 2) the RP does not verify the binding between the portable identifier and the IdP-specific identifier in the response. to the one the attacker controls and the IdP has mapped This is the part where I think you're wrong. The RP MUST verify that binding, whether it is by keeping state, self-signing the request (which gets passed through to the response) or doing discovery again. I agree the RP SHOULD do that. The proposal does not specify that. I thought we had that conversation. I have not looked at the patch that you sent. Perhaps you address the issue there. My point though is: why have the RP bind the IdP-specific identifier and the public identifier? Why not let the IdP be responsible for this? In 1.x when the IdP was not aware of the public identifier, then the RP had to do the binding. Now that the IdP is aware of the public identifier, it would be simpler and logical for the IdP to be responsible for the binding. It is doing it anyway. All the RP wants is which public identifier is the user, and is the IdP authoritative for it. If delegation is going to require cooperation from the IdP anyway, there's no longer any value in having the distinction between a public identifier and an IdP-local identifier. The hypothetical IdP IdP-tastic can just store a relationship between http://mart.vanitydomain.com/ and my user account at IdP-tastic. There's no need for http://mart.idp-tastic.com/ anymore, and with that gone delegation is no longer useful: the public identifier, whatever it might be, is the only identifier. Any disadvantages to uniting the public identifier and the IdP identifier are also disadvantages of having the IdP do the binding as you describe. For simplicity's sake, I'm currently only willing to vote positively for one of the following scenarios: * Have only one identifer in the protocol. Remove delegation entirely. IdP maintains relationships between arbitrary identifiers and its local user accounts. IdP no longer needs to issue its own identifiers, though it can if desired. This makes life simpler for RPs, but has the risk that delegation would become an IdP premium feature, which may hurt users in the long term. * Protocol has two distinct identifiers: public and IdP-local. Relying party manages delegation. IdP does not even know that the delegation has taken place and has no way to stop it happening [1]. RP now has to do more work, but identifier portability now comes for free. Having the IdP deal with the public identifier while still keeping the IdP-local identifier (and thus delegation) is, it seems to to me, muddled nonsense; the whole purpose of delegation was to make these identifiers distinct. [1] Conceivably a mischievous IdP could make use of knowledge of how particular RPs round-trip their delegation state to block it, but that would be an arms race in the RP's favour rather than a designed-in mechanism for detecting delegation. ___ 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: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
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
Re: [PROPOSAL] Handle [EMAIL PROTECTED] For Discovery Only
Title: Re: [PROPOSAL] Handle [EMAIL PROTECTED] For Discovery Only I guess I shouldn't have said http://[EMAIL PROTECTED]. All that is being suggested is the following language (on my Treo): If a string in the format of [EMAIL PROTECTED] at a RP, the RP MUST treat the domain after @ as the IdP Identifier. The protocol continues down the normal directed identity flow. --David -Original Message- From: Johannes Ernst [mailto:[EMAIL PROTECTED]] Sent: Friday, October 20, 2006 02:07 PM Pacific Standard Time To: specs@openid.net Subject: Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers We actually built some code some time ago to explore this. The basic insight was: if we can do Yadis discovery on XRIs (which aren't rooted in DNS), then we can do Yadis discovery on any other kind of identifier, whether it's an e-mail address or an ISBN number or what have you -- and once we have a Yadis file for a given identifier, we are home free because it essentially maps that identifier into HTTP. We considered three or four different ways of doing Yadis resolution from e-mail addresses and the like, including the http:// [EMAIL PROTECTED]/ idea that David mentions; under the hood they are different, but what the user sees is the same. Usability is the key problem here: - we confuse the user because suddenly it's not URL-based identity any more - we confuse the user because users aren't clickable any more (except for a mailto: tag, which is confusing in its own right it most identities pop up a blog or home page) - we confuse the user because if I type the identifier into by browser's address bar, it pops up a phishing warning (!) instead of the user's home page. We decided that for the time being, it was going to be much easier to educate users on the need to use URLs as identifiers, than to educate users to not be confused by the above behaviors. The situation would change if, say, Mozilla and MSFT were performing Yadis discovery on e-mail-style identifiers, and directed the user to their (http) home page from a given e-mail address. Not impossible to imagine, but certainly not something to expect any century from now. On Oct 20, 2006, at 13:44, Jonathan Daugherty wrote: # I'm not actually proposing the IdP make an assertion about # [EMAIL PROTECTED] It would only be used during the discovery phase # and then an assertion for a URL be returned. Ok, I misunderstood. But even in the case where the IdP makes an assertion about a different identifier, that's confusing, too; you enter something that looks like an email (and maybe your provider tells you it even is), but you log into the site as something else, right? -- Jonathan Daugherty JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs Johannes Ernst NetMesh Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID.net Service Type Namespaces
Right now we have things like http://openid.net/signon/1.1, http://openid.net/sreg/1.0, etc. This doesn't really seem to scale, populating the main http://openid.net namespace. Could we do something like http://specs.openid.net/authentication/2.0/signon or http://specs.openid.net/authentication/2.0/identifier_select as well as then http://specs.openid.net/sreg/1.0? This would give all the specs their own namespaces, as well as make it so we can do smart redirection from each of these type urls to the correct anchor in the individual spec. --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Question: multiple IdPs?
Upload an XML file and add a meta-tag which points to it... Somehow I doubt that someone who can't do that will really be interested in the use case you described. In any case, it is surprising what people can do when following Internet tutorials. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Thursday, October 19, 2006 12:01 AM To: Recordon, David Cc: Drummond Reed; specs@openid.net Subject: Re: Question: multiple IdPs? Forgive my lack of Yadis configuration expertise, but is this something that your average blogger can add to their WP or MT blog? -- Dick On 18-Oct-06, at 7:28 AM, Recordon, David wrote: At that point then I'd argue that the feature shouldn't be supported; Yadis was developed to handle use cases like this. While HTML-based Discovery is certainly easier, I'm happy not adding to it beyond what was in 1.1 and telling people to use Yadis when they need something more complex. I think that is a good balance between light-weight discovery and features. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Wednesday, October 18, 2006 3:27 AM To: Drummond Reed Cc: specs@openid.net Subject: Re: Question: multiple IdPs? Thanks Drummond, but what if I am using HTML-based discovery? (that is what I am going to use in my vanity domain, much easier to implement) http://openid.net/specs/openid-authentication-2_0-10.html#html_disco -- Dick On 17-Oct-06, at 11:46 PM, Drummond Reed wrote: In the directed identity case, the IdP URL or XRI you give to the RP resolves to your IdP's XRDS document. Each of your IdPs would have a different one. If they support directed identity, each would have a Service with a Type tag value of http://openid.net/identifier_select/2.0. This service endpoint would not have an OpenID:Delegate tag (or if it does the spec should be clear that it is ignored for this service type) since this service provides directed identity authentication for everyone at that IdP. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Tuesday, October 17, 2006 11:25 PM To: specs@openid.net Subject: Question: multiple IdPs? I would like to use different IdPs for my vanity URL, blame.ca. In an OpenID 2.0 world, I can provide either of my IdP URLs to the RP and then select blame.ca and login. Does this work? What having two openid.server tags suffice? How would the RP know which delegate tag goes with which IdP? The spec is not silent on this. ( and yes, another argument for having one identifier so that the RP does not have to figure out anything about the delegate tag since it does not do anything with it anyway!) -- 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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: PROPOSAL: OpenID Form Clarification (A.4)
The spec is an authentication spec which does not discuss rich clients anywhere. As I've said, and I'd think others would agree, it is not a requirement of the spec to enable rich clients. It is great to have them and great for it to enable them. Whether the spec says this is a MUST or not you'll still have to tell users that not all relying parties will support the use of the rich client. It seems presumptuous for us to think that by making this a MUST we'll be able to force every relying party into doing it, when to them not doing it doesn't actually break anything within the authentication protocol. Six months from now this may be a different story, but for now I guess we just don't see eye to eye on the issue. :-\ --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Thursday, October 19, 2006 12:08 AM To: Recordon, David Cc: Jonathan Daugherty; specs@openid.net Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) Please see the RFC. SHOULD is used if there is a valid reason for it not being a MUST. If the RP does not have the tag, the a rich client will not work. Authentication cannot proceed. That is broken as far as the user is concerned. What if doing HTML disco was a SHOULD instead of a MUST? Then that RP would not work with certain identifiers. -- Dick On 18-Oct-06, at 8:58 PM, Recordon, David wrote: In my view, it is because the authentication protocol can proceed with no problems if this field is named something different. As things won't break, as far as the protocol is concerned, this would also be nearly impossible to enforce or justify. It is easy to tell a developer to fix how they're creating signatures, authentication transactions do not complete, but enforcing convention around form fields seems difficult at best. I'd imagine that if a RP does not follow this recommendation then a rich client should treat it as not being a relying party. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 18, 2006 11:35 PM To: Recordon, David Cc: Jonathan Daugherty; specs@openid.net Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) Why SHOULD rather then MUST? [1] What valid reason is there for an RP to not have that field name? [1] http://www.ietf.org/rfc/rfc2119.txt -- Dick On 18-Oct-06, at 1:28 PM, Recordon, David wrote: Agreed, just like the spec already says The form field's name attribute SHOULD have the value openid_identifier as to allow User Agents to automatically prefill the End User's Identifier when visiting a Relying Party. I'm all for this feature, as well as even identifying the form itself, though don't see how it should be a MUST over a SHOULD for a Relying Party. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Daugherty Sent: Wednesday, October 18, 2006 2:33 PM To: Dick Hardt Cc: specs@openid.net Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) # Proposal # # Modify 8.1 to: # ... # # The form field's name attribute MUST have the value # openid_identifier as to allow User Agents to automatically prefill # the End User's Identifier when visiting a Relying Party. This should be a SHOULD, not a MUST. -- 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
RE: Question: multiple IdPs?
Sorry, pointer to Josh's email? Yeah, the XML file can be based elsewhere. Might be worth a quick skim of the Yadis spec (http://yadis.org/papers/yadis-v1.0.pdf) Only three pages, section six, which talks about this. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Thursday, October 19, 2006 12:12 AM To: Recordon, David Cc: Drummond Reed; specs@openid.net Subject: Re: Question: multiple IdPs? Agreed that it is a power user that wants multiple IdPs, but per Josh's email. someone can't use OpenID 2.0 unless they do this. I think that is a very common use case. Can the meta-tag point to an XML file on another site? (sorry for being lazy and not figuring it out myself) (multiple IdP support would lead the user to want to have created their own XML file) -- Dick On 18-Oct-06, at 9:05 PM, Recordon, David wrote: Upload an XML file and add a meta-tag which points to it... Somehow I doubt that someone who can't do that will really be interested in the use case you described. In any case, it is surprising what people can do when following Internet tutorials. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Thursday, October 19, 2006 12:01 AM To: Recordon, David Cc: Drummond Reed; specs@openid.net Subject: Re: Question: multiple IdPs? Forgive my lack of Yadis configuration expertise, but is this something that your average blogger can add to their WP or MT blog? -- Dick On 18-Oct-06, at 7:28 AM, Recordon, David wrote: At that point then I'd argue that the feature shouldn't be supported; Yadis was developed to handle use cases like this. While HTML-based Discovery is certainly easier, I'm happy not adding to it beyond what was in 1.1 and telling people to use Yadis when they need something more complex. I think that is a good balance between light-weight discovery and features. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Wednesday, October 18, 2006 3:27 AM To: Drummond Reed Cc: specs@openid.net Subject: Re: Question: multiple IdPs? Thanks Drummond, but what if I am using HTML-based discovery? (that is what I am going to use in my vanity domain, much easier to implement) http://openid.net/specs/openid-authentication-2_0-10.html#html_disco -- Dick On 17-Oct-06, at 11:46 PM, Drummond Reed wrote: In the directed identity case, the IdP URL or XRI you give to the RP resolves to your IdP's XRDS document. Each of your IdPs would have a different one. If they support directed identity, each would have a Service with a Type tag value of http://openid.net/identifier_select/2.0. This service endpoint would not have an OpenID:Delegate tag (or if it does the spec should be clear that it is ignored for this service type) since this service provides directed identity authentication for everyone at that IdP. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Tuesday, October 17, 2006 11:25 PM To: specs@openid.net Subject: Question: multiple IdPs? I would like to use different IdPs for my vanity URL, blame.ca. In an OpenID 2.0 world, I can provide either of my IdP URLs to the RP and then select blame.ca and login. Does this work? What having two openid.server tags suffice? How would the RP know which delegate tag goes with which IdP? The spec is not silent on this. ( and yes, another argument for having one identifier so that the RP does not have to figure out anything about the delegate tag since it does not do anything with it anyway!) -- 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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Notes From Draft 10
While I've already incorporated many of the things I found in draft 9 into 10, there were a few things which I didn't either have the right answer to or feel that I could make the change on my own. I tried reading through the draft as if I was reading it for the first time. 4.2 Integer Representations It seems that this section should have some sort of normative reference, though I'm unsure what document should be referenced. 5.1 Direct Communication A new term IdP endpoint URL is introduced, is this something that needs to be defined? 5.1.2 Direct Response The content-type of the response SHOULD be text/plain. Is there a case when the response is valid and it isn't text/plain? 5.1.2.1 A server receiving a properly formed request MUST send a response with an HTTP status code of 200. I trust server is referring to an IdP given the setup in 5.1, it seems this will become clearer along with a definition to IdP endpoint URL. Do we need to say anything more than a properly formed request? Seems like a forward reference may make sense here. 6.1 Signed List Algorithm 1. Iterate through the list of keys to be signed in the order they appear. I spoke with the guys up at JanRain about this Friday in terms of if we'd like to be more explicit in the ordering of the arguments being signed. Right now the algorithm works as in 1.1, where the data is signed per the order in the openid.signed argument. I'm worried that this works more out of convention rather than a conscious decision that this is the right way to do it. While it would change signature generation from 1.1, I'm thinking it would make sense to change this algorithm to first alphabetically sort the arguments to make it very clear in terms of ordering. 7.1 Procedure I added forward references in draft 10, though am wondering if we should expand on each bullet in this overview. 9.1 Initiation Do we wish to recommend a value for the id attribute on the form tag that the RP presents to the EU? We already recommend the field be named openid_identifier, though I'm thinking adding the same sort of recommendation to the form itself will better enable browser extensions. 9.3.2 XRDS-Based Discovery It seems we have no normative, or even non-normative, references to describe the XRDS document. What is the correct OASIS spec to reference? 3.2 Unsuccessful Response Parameters If no association is established, the Relying Party MAY continue the authentication process in stateless mode. It doesn't seem we ever define stateless mode or have a good place in the document to reference here. 11.1 Request Parameters Note: If this is set to the special value http://openid.net/identifier_select/2.0;, the IdP MAY choose an identifier that belongs to the End User. Seems like this could be reworded. 12 Responding to Authentication Requests If the association is missing or expired, the IdP SHOULD send the openid.invalidate_handle parameter of the response to the requests openid.assoc_handle, and SHOULD proceed as if no association handle was specified. Seems like this should be reworded. 13.2.2.2 Response Parameters An IdP MUST NOT verify signatures for associations that have shared MAC keys. Seems like the definition of a shared MAC key should be given at this point. 14 OpenID Authentication 1.1 Compatibility Should this section be combined with A.C Changes from Previous OpenID Authentication Specification. I think keeping them separate is good, 14 speaks to things that affect implementers while A.C speaks to motivations and general changes. Just seems like a forward reference may be useful. Thoughts? 16 Discovering OpenID Authentication Relying Parties I think this section was meant to have been removed in a prior draft.?. In any case, I think removing it now makes sense given the recent discussion of having the RP advertise the location of their XRDS document as a request parameter. Thoughts? --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Summarizing Where We're At
And here are my votes: Request nonce and name * Take no action Authentication age * -1, write as an extension first Remove setup_url * 0 for removing, +1 for asking feedback from implementers Consolidated Delegation Proposal * -1 on status quo (draft 10) * 0 on single-identifier * +1 on two-identifier Change default session type * +1 Bare request * 0 --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Monday, October 16, 2006 11:21 AM To: Recordon, David Cc: specs@openid.net Subject: Re: Summarizing Where We're At Here are my reactions to what's outstanding: On 10/15/06, Recordon, David [EMAIL PROTECTED] wrote: * Request Nonce and Name - Has been partially implemented, openid.nonce - openid.response_nonce, no agreement on the need of a request nonce specifically, rather discussion has evolved into allowing a RP to pass appdata like in Yahoo's BBAuth. No formal proposal on the table yet, thus will not be included in this version. Take no action * Authentication Age - Re-proposed today adding clarity in motivation, general consensus is needed to add to specification. -1 * Remove setup_url - Little discussion and no general consensus to do so. Rather seems asking for feedback from checkid_immediate implementers on the parameter would be beneficial at this time. +1 * Consolidated Delegation Proposal - Very active discussion, the only proposal I'm willing to stall the spec for. Seems very important a strong conceptual model is created at this time. -0 on status quo (draft 10) +0 on single-identifier +1 on two-identifier * Change Default session_type - Proposed, no discussion yet. Will address in separate message * Bare Request - Proposed, no discussion yet. -0 (YAGNI) Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Delegation discussion summary
After re-reading this, other messages, and Dick's latest post, I strongly feel that we should make the change to support both the portable and IdP-specific identifiers within the protocol. The two most compelling reasons to me are that it has the fewest conceptual changes from OpenID Auth 1.x and the messages are very verbose and explicit in both the request and response. In addition, I believe it will grant greater flexibility for extensions being built atop the protocol as well as it provides useful features when working with XRIs. I appreciate the simplicity the one identifier approach presents, though dislike changing the concept behind the protocol this late in the drafting process. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Thursday, October 12, 2006 10:29 AM To: specs@openid.net Subject: Delegation discussion summary Hello, list, I'm sure that another message in your inbox with delegation in the title makes most of you cringe, so I'm sorry for that.I hope that this one gets us closer to resolving this issue. I have attempted to summarize the proposed delegation mechanisms, as well as the currently-specified delegation mechanism in a single document. I have glossed over some issues and left out some of the discussion, but I hope that I captured most of the important stuff. After reviewing the discussion, I think that we are actually pretty close to consensus on a course of action. I have added one new thing in this write-up, which is that I have started calling delegation portable identifier support, which gives rise to the term portable identifier for what is currently called a delegated identifier. I think that this terminology is a little easier to understand and less loaded than calling it delegation. My write-up follows. Josh OpenID portable identifier support ## Portable identifier support allows an IdP to do authentication for an identifier that was not issued by that IdP. It has two motivating use cases [1]_: * allow users to use any identifier with any IdP * allow users to move an identifier between IdPs (prevent IdP lock-in) Each portable identifiers has an IdP-specific identifier tied to it. This identifier allows the IdP to know what credentials to require before issuing an authentication response even though the IdP does not control the portable identifier. Throughout this discussion, I will assume that there is a portable identifier called http://my.portable.url/; that uses an IdP-specific identifier called http://my.idp.specific.url/;. Current implementation == OpenID 1 [2]_ calls portable identifier support delegation. In this implementation, the IdP-specific identifier is the only identifier that is communicated between the relying party and the IdP. When a relying party discovers that it is requesting authentication for a portable identifier, it must keep that state available for processing the response, since the response message does not contain the portable identifier at all. Request and response messages for this mechanism both use the following field:: openid.identity = http://my.idp.specific.url/ This mechanism has a few drawbacks: * The relying party must manage state information for the duration of the transaction. * The authentication messages are potentially confusing, since the authentication response is not meaningful without the context of the initiation, and the IdP-specific identifier does not even have to be a valid OpenID identifier. * The IdP *cannot* be aware that it is using a portable identifier, so the IdP cannot assist the user in making decisions for different identifiers. For example, a user might wish to be prompted for confirmation each time he used one identifier, but allow automatic approval for another. * IdP-driven identifier selection in the OpenID 2.0 specification (up to draft 9) cannot return assertions for portable identifiers, because the verification algorithm will fail. * Portable identifiers must be treated differently from IdP-issued identifiers by the code running on the relying party Proposed changes All of the changes to delegation that have been proposed retain the important features of portable identifier support. Additionally, they all retain the same basic structure, where the IdP-specific identifier is available from the standard discovery process. Primarily, the proposals change what data is available in the protocol messages, the relationship of the request to the response, and/or the party who is responsible for discovering the IdP-specific identifier for the portable identifier. Both of the proposed changes to the response messages include the portable identifier in the authentication response. Changing the response to contain the portable identifier removes the burden of maintaining that state from the relying
