OpenID Authentication 2.0 Draft 10 Posted
With a good deal of work from both Josh and I this past week, we now have Draft 10 (http://openid.net/specs/openid-authentication-2_0-10.html)! While I previously proposed this be the final draft, the delegation proposal is still being actively discussed and it is quite important consensus be reached before I'd be comfortable calling the spec final. I'll also be posting various questions I have, sometime in the next day or two, after fully re-reading the specification today. --David Changelog: - Rename trust_root to realm - Remove SIGNALL - Rename nonce to response_nonce, though do not add a request nonce - Add http://openid.net/signon/1.1 as an XRD Service type, since it is present in the wild. Indicate that it triggers compatibility mode. - Update August to October - Use OpenID and OpenID Authentication as appropriate - Reorder terminology section - Make Identity Provider the defined term, with IdP as the short-hand - Link to RFC when defining Diffie-Hellman Key Exchange - Fix various typos and cleanup wording - In 3.5, note that EU - IdP auth is out of scope - Note that in 4.1.2 openid. is only prefixed on request messages - Combine Signature Algorithms and Procedure into one uber Signatures section, though this still needs to be cleaned up more - Add motivation to OpenID logo in form field - Enumerate XRI Global Context symbols - Note the RP should keep the normalized/redirected URL as the Claimed Identifier - Swap 10.3 and 10.4 due to order introduced - Add additional cross-references - Add mode in 13.2.2.2 as a response parameter instead of only listing it as a request parameter - Update 9.3.3 to require support of 1.1 HTML-based discovery to match 14.1 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On 10/13/06, Drummond Reed [EMAIL PROTECTED] wrote: So whether it's in the spec formally or not, I don't really care. But the spec MUST contain details on the precautions a RP should take. Yup.(Got that, editors?) http://openid.net/specs/openid-authentication-2_0-10.html#anchor38 Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On 10/13/06, Chris Drake [EMAIL PROTECTED] wrote: DR CASE 1: the protocol supports only IdP-specific identifiers and no portable DR identifiers. DR RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1. Please explain? If I've got an OpenID URL (eg: my vanity domain), I can transfer this via DNS (or just update my OpenID LINK). If I've got an i-name, I can transfer this too. Where's the lock in ? This is true assuming that IdPs have uniform support for registering an identifier that it did not issue. OpenID 1 addressed this in its architecture. In OpenID 1, the identifier does not even have to be registered with the IdP. The proposed changes alter this arrangement. In the 2-identifier proposal, the IdP does not need to support registering identifiers, but it can be aware that a third-party identifier is being used. In the one-identifier proposal, the IdP is solely responsible for being aware of the arrangement. I do not think the success of the protocol rides on this decision, but I think it's important to understand, and understand the implications of the choice that is made. In many ways, the spirit of OpenID has been to empower the user above all. OpenID 1's delegation is consistent with that. I do not believe the RP needs to know the IdP-specific identifier ever (worse: I think it should never be allowed to know it, or even be allowed to see it!). Why not? Yes - we need 2 identifiers - but from the point of view of the specs - the OpenID protocol really only needs to deal with one. See above. There seem to be a lot of people on this list who want to hate and loathe the IdP, and grant all power to the RP. I do not understand this reasoning: our users will select the IdP they trust and like, then they will be using a multitude of possibly hostile RPs thereafter: the reverse is simply not true. Where is power being granted to the RP? It has pretty much none. It *does* have responsibility, but only as much as is necessary to make the protocol work. Can we not adopt my earlier suggestion: just ensure OpenID can permit IdP-initiated logins. This permits every scenario of portability (and privacy) that everyone wants, without us having to continue to debate it ? Huh? How is IdP-initiated login related to privacy or portability? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
Brad Fitzpatrick wrote: Counter-argument: but OpenID 1.1 does have two parameters: one's just in the return_to URL and managed by the client library, arguably in its own ugly namespace (not IdP/RP managed, not openid., but something else... the Perl library uses oic. or something). So then it's harder to document the correct behavior to people (RPs should verify the mapping when you get a signature!) because the parameter names aren't consistent between RP clients. Not specifying it gives RPs the freedom to put whatever handle they want in the return_to, though. If they *are* able to maintain state, they might have some arg like ?handle=1380a383198bcefd933, which is completely opaque to everone except the RP. I'd rather avoid specifying things we don't need to specify, since it leaves more flexibility for implementors in an area where this flexibility doesn't do any harm. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: Identifier portability: the fundamental issue
Hi Josh, I do not believe the RP needs to know the IdP-specific identifier ever (worse: I think it should never be allowed to know it, or even be allowed to see it!). JH Why not? PRIVACY. Page back and read trough my posts to this list for the intricate details. JH Where is power being granted to the RP? It has pretty much none. JH It *does* have responsibility, but only as much as is necessary to JH make the protocol work. If RPs are allowed to build up linked portfolios of everyones identifiers, they can get together with other RPs (or sniff IDs in google) to snoop on and conspire against our users behind their backs. If the true spirit of OpenID is to empower users, it's seriously neglectful to block users from protecting their own privacy. Can we not adopt my earlier suggestion: just ensure OpenID can permit IdP-initiated logins. This permits every scenario of portability (and privacy) that everyone wants, without us having to continue to debate it ? JH Huh? How is IdP-initiated login related to privacy or portability? It is ** NONE OF THE RPs BUSINESS ** how the OpenID that got presented to it was originally selected by, or resolved for, our Users. Letting the IdP initiate a login allows the IdP to PRIVATELY negotiate with the user over which identity to present (which for anyone who cares about privacy, will usually be a per-site identity not linked to their main OpenID or vanity domain or whathaveyou.). The beauty of this suggestion is that we don't even need to debate it: so long as IdP initiated logins are supported, market forces will then decide whether or not privacy and security become widespread in OpenID. I'm not saying this should be the *only* way an OpenID login can take place - just that if this simple concept is implemented, that we can then defer all privacy issues to the IdPs in future, and concentrate now on getting this spec out the door. -- I notice the current spec: http://openid.net/specs/openid-authentication-2_0-10.html does not even *mention* privacy? (besides the allusion in the abstract: It does this without the Relying Party needing access to password, email address, or other sensitive information. - but somehow nobody's understanding that the users OpenID *itself* is sensitive information, especially in the way google will in future let anyone troll back through our users online tracks using this ID...) Also missing are 16. Security Considerations and 16.1. Preventing Attacks Perhaps someone should add a section on privacy, and someone should take a crack at the security aspects! Who is in charge of writing this stuff? I've submitted 102 (one hundred and two!!!) security considerations in the posts I've made to this list so far: Shouldn't someone be documenting this? Chris. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
[EMAIL PROTECTED]
Should you wish to track changes to the website or specifications, feel free to join this list. http://openid.net/mailman/listinfo/commits --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
[PROPOSAL] Changing the Default Session Type for Associations
Currently the default encryption type for openid.session_type when creating a new association is no-encryption. This stems from OpenID Authentication 1.1 where when the parameter was not included in the request it meant no encryption. I'd recommend that this default value be changed to DH-SHA1 so that implementers have to specifically request weaker security rather than explicitly having to request stronger security when transporting the MAC key. In a public environment, no encryption should only be used when using transport layer security. The potential downside is that this will change the default value between 1.1 and 2.0 messages. I do not believe this is a strong enough reason to not make this change, but rather it should be documented in the OpenID Authentication 1.1 Compatibility section. I know we're very close to wrapping up the protocol, but feel this is important enough to propose at this time. --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Identifier portability: the fundamental issue
Chris, I totally agree that: a) OpenID Authentication 2.0 should support yours scenario of IdP-initiated login, and b) that this enables a whole range of privacy solutions, many of which can be supported by IdP innovation. If IdP-initiated login were the only use case, then only one identifier would be needed. It's the use cases for RP-initiated login that argue for having a second identifier parameter in the protocol. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Drake Sent: Friday, October 13, 2006 9:19 PM To: specs@openid.net Subject: Re: Identifier portability: the fundamental issue Hi Drummond, DR CASE 1: the protocol supports only IdP-specific identifiers and no portable DR identifiers. DR RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1. Please explain? If I've got an OpenID URL (eg: my vanity domain), I can transfer this via DNS (or just update my OpenID LINK). If I've got an i-name, I can transfer this too. Where's the lock in ? I do not believe the RP needs to know the IdP-specific identifier ever (worse: I think it should never be allowed to know it, or even be allowed to see it!). Yes - we need 2 identifiers - but from the point of view of the specs - the OpenID protocol really only needs to deal with one. There seem to be a lot of people on this list who want to hate and loathe the IdP, and grant all power to the RP. I do not understand this reasoning: our users will select the IdP they trust and like, then they will be using a multitude of possibly hostile RPs thereafter: the reverse is simply not true. Can we not adopt my earlier suggestion: just ensure OpenID can permit IdP-initiated logins. This permits every scenario of portability (and privacy) that everyone wants, without us having to continue to debate it ? This really *is* only an hour or two's worth of code: after which, market forces can decide which bells and whistles relating to portability and privacy the IdPs choose to implement - from the OpenID point of view, it's all just going to work. Kind Regards, Chris Drake, =1id.com Saturday, October 14, 2006, 5:59:23 AM, you wrote: DR CASE 2: the protocol supports only portable identifiers and no IdP-specific DR identifiers. DR RESULT: IdP is forced to know and store all portable identifiers for a user, DR including identifiers for which the IdP is not authoritative, and users DR would be forced to register all their portable identifiers with their IdP, DR and to update these registrations every time the user adds or deletes a DR portable identifier. Highly undesirable if not impossible. DR * DR Please post if you do not agree with this postulate. DR =Drummond DR ___ DR specs mailing list DR specs@openid.net DR http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RP attack vector - why two identifiers are redundant
On 13-Oct-06, at 7:45 PM, Drummond Reed wrote: And despite all the but it can't be stateless without two! noise, it actually can: you put the portable identifier in the return_to URL and verify it again when you get the signature back from the IdP. That is, verify the mapping from portable - IdP-specific still holds. Because you can't just trust the 1 (or 2) values you get back from the IdP, otherwise the IdP (which could be malicious) could be fucking with you, asserting a portable identifier which it's not actually permitted to do, according to the portable identifer's YADIS/head/etc. Good point. I've never figured an attack vector for the RP to send the wrong identifiers to the IdP, since the RP is just fooling itself. But I agree there can be one for a malicious IdP to return the wrong ones to an RP. The attack vector is not that the RP sends the wrong identifiers, it is that a malicious user in between modifies the request that is sent to the IdP. Since the request is not signed and flows through the user, the IdP does not know the request message has not been modified. If the IdP assumes the two identifiers are bound, then a malicious user can pretend to be a different user from the same IdP to the RP. This presumes the IdP is using an IdP identifier and the RP is using an RP identifier and the binding is assumed by sending both. Therefore, the IdP MUST make sure the two identifiers are linked, so sending both is redundant for the IdP. As noted in other messages, the RP cannot trust the IdP binding, and needs to verify the binding themselves, so the sending the two parameters is redundant in the response as well. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Re[2]: Identifier portability: the fundamental issue
On 14-Oct-06, at 7:28 AM, Chris Drake wrote: JH Where is power being granted to the RP? It has pretty much none. JH It *does* have responsibility, but only as much as is necessary to JH make the protocol work. If RPs are allowed to build up linked portfolios of everyones identifiers, they can get together with other RPs (or sniff IDs in google) to snoop on and conspire against our users behind their backs. If the true spirit of OpenID is to empower users, it's seriously neglectful to block users from protecting their own privacy. NOTE: There are instances when the user will WANT the RPs to know they are the same user across sites. Right now my reputation on a site is locked into that site. No other site can know that I have done things on other sites, so that I can go to a new site and take my reputation with me. Real world example: when I give a talk, I use the same identifier so that people know it is me. I use the same email on different mailing lists so people know it is the same person. Can we not adopt my earlier suggestion: just ensure OpenID can permit IdP-initiated logins. This permits every scenario of portability (and privacy) that everyone wants, without us having to continue to debate it ? JH Huh? How is IdP-initiated login related to privacy or portability? It is ** NONE OF THE RPs BUSINESS ** how the OpenID that got presented to it was originally selected by, or resolved for, our Users. Letting the IdP initiate a login allows the IdP to PRIVATELY negotiate with the user over which identity to present (which for anyone who cares about privacy, will usually be a per-site identity not linked to their main OpenID or vanity domain or whathaveyou.). I completely agree. This was the major issue Sxip had with OpenID 1.x. The user had to identify themselves with no assistance from their IdP, and hence no support for directed identity. The beauty of this suggestion is that we don't even need to debate it: so long as IdP initiated logins are supported, market forces will then decide whether or not privacy and security become widespread in OpenID. As we are building and testing software, it is interesting as to what become the common cases. More later. :-) I notice the current spec: http://openid.net/specs/openid-authentication-2_0-10.html does not even *mention* privacy? (besides the allusion in the abstract: It does this without the Relying Party needing access to password, email address, or other sensitive information. - but somehow nobody's understanding that the users OpenID *itself* is sensitive information, especially in the way google will in future let anyone troll back through our users online tracks using this ID...) Also missing are 16. Security Considerations and 16.1. Preventing Attacks Perhaps someone should add a section on privacy, and someone should take a crack at the security aspects! Who is in charge of writing this stuff? I've submitted 102 (one hundred and two!!!) security considerations in the posts I've made to this list so far: Shouldn't someone be documenting this? Yes, these things do need to be addressed. Would be great to get additional seasoned security gurus to review and comment. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Re[2]: [PROPOSAL] request nonce and name
Also note that URL parameters are not secured by TLS in HTTPS. -- Dick On 13-Oct-06, at 3:57 AM, Chris Drake wrote: Hi All, Just so everyone remembers: GET encoded http://; URLs usually appear en-mass in public lists (from proxy cache logs). If you don't want to POST data anyplace, remember to expect replay attacks often. Kind Regards, Chris Drake Friday, October 13, 2006, 7:48:31 PM, you wrote: JH On 10/13/06, Martin Atkins [EMAIL PROTECTED] wrote: True, even one single pass through parameter should do. This causes the minor inconvenience that the RP will probably now have to implement its own parsing, rather than using the framework's pre-supplied functions for dealing with urlencoded query strings. Not a major deal, but I'd guess that this is where the idea to use return_to args came from in the first place. JH return_to arguments can only be trusted if they are taken from the JH signed return_to parameter, which means parsing the signed return_to JH parameter anyway. So it's at least no worse. JH It's better in that the parameters do not now appear twice in the JH response (once double-encoded) JH Example of a response with parameter in the return_to: JH http://a.url/?drink=0xC0FFEE%21openid.return_to=http%3A//a.url/ %3Fdrink%3D0xC0FFEE%2521... JH Example of a response with hypothetical openid.appdata field: JH http://a.url/?openid.appdata=drink%3D0xC0FFEE% 21openid.return_to=http%3A//a.url/... JH Josh JH ___ JH specs mailing list JH specs@openid.net JH http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: RP attack vector - why two identifiers are redundant
Dick, While it is true that the IdP should still check that they are bound, except in the case when it is directly authoritative for both, the RP should provide the IdP with what the user entered as a hint to what claim the End User is wishing to make. Just sending the non-portable identifier, as is done today, means that smart IdPs will have to prompt the user again for what they just typed into the RP. While the protocol certainly can work without both, I believe it is a cleaner conceptual model to have the RP pass both to the IdP and then the IdP verify as needed. If we run into the problem of an End User not wanting the IdP to know the portable identifier, then I think that is a great thing as it means we've wrapped up Auth 2.0 and a lot of people are using it in many different ways! :) --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Saturday, October 14, 2006 7:12 PM To: Drummond Reed Cc: specs@openid.net Subject: RP attack vector - why two identifiers are redundant On 13-Oct-06, at 7:45 PM, Drummond Reed wrote: And despite all the but it can't be stateless without two! noise, it actually can: you put the portable identifier in the return_to URL and verify it again when you get the signature back from the IdP. That is, verify the mapping from portable - IdP-specific still holds. Because you can't just trust the 1 (or 2) values you get back from the IdP, otherwise the IdP (which could be malicious) could be fucking with you, asserting a portable identifier which it's not actually permitted to do, according to the portable identifer's YADIS/head/etc. Good point. I've never figured an attack vector for the RP to send the wrong identifiers to the IdP, since the RP is just fooling itself. But I agree there can be one for a malicious IdP to return the wrong ones to an RP. The attack vector is not that the RP sends the wrong identifiers, it is that a malicious user in between modifies the request that is sent to the IdP. Since the request is not signed and flows through the user, the IdP does not know the request message has not been modified. If the IdP assumes the two identifiers are bound, then a malicious user can pretend to be a different user from the same IdP to the RP. This presumes the IdP is using an IdP identifier and the RP is using an RP identifier and the binding is assumed by sending both. Therefore, the IdP MUST make sure the two identifiers are linked, so sending both is redundant for the IdP. As noted in other messages, the RP cannot trust the IdP binding, and needs to verify the binding themselves, so the sending the two parameters is redundant in the response as well. ___ 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: RP attack vector - why two identifiers are redundant
On 14-Oct-06, at 7:36 PM, Recordon, David wrote: Dick, While it is true that the IdP should still check that they are bound, except in the case when it is directly authoritative for both, the RP should provide the IdP with what the user entered as a hint to what claim the End User is wishing to make. Just sending the non-portable identifier, as is done today, means that smart IdPs will have to prompt the user again for what they just typed into the RP. I think the RP should ALWAYS send a normalized version of what the user typed in. There is no need to send what got resolved, as both the IdP and the RP will need to resolve it. (I am almost caught up on list email, and will write up yet-another- identifier-email. :-) While the protocol certainly can work without both, I believe it is a cleaner conceptual model to have the RP pass both to the IdP and then the IdP verify as needed. If we run into the problem of an End User not wanting the IdP to know the portable identifier, then I think that is a great thing as it means we've wrapped up Auth 2.0 and a lot of people are using it in many different ways! :) I thought we already had determined that the IdP will know the portable identifier? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Delegation discussion summary
Would you elaborate on those use cases? The current draft does not support this. -- Dick On 13-Oct-06, at 8:52 AM, Granqvist, Hans wrote: I can see potential use-cases where Alice doesn't want the idp to know what her portable URL is. This would not work if the protocol requires both as per below. Can it be solved by sending a hash of the portable identifier? -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 party. Removing this dependency on transaction state enables portable identifiers to be used in both IdP-driven identifier selection and IdP-initiated authentication (bare response) [3]_. Neither proposal outlined here changes the protocol
Re: Delegation discussion summary
I would propose that the term Homesite be used when prompting the user to type in their IdP. I think the term Identity Provider is overloaded and not user friendly. As per my last email I feel the same way about identity provider as well ... I agree with Dick; too overloaded and not user friendly. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Delegation discussion summary
I kinda get homesite, but I don't understand the thinking behind membersite: What is this site supposed to be a member of? It was a member of the network of sites running the protocol. Membersite sounds too much like you have to join some club to participate. I feel the same way about homesite. I'm all for finding more consumer-friendly terminology for this but I've yet to hear anything that rings true. In the case of http you have web server which is served up by a web site ... Instead of http provider and http destination ... Maybe we need to make this even simpler than we are? Could it be as simple (and I'm not really suggesting these) as login server and login site? What does the wider community think? How do LiveJournal users refer to this concept today? - Scott ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: RP attack vector - why two identifiers are redundant
On 10/14/06, Dick Hardt [EMAIL PROTECTED] wrote: Since the request is not signed and flows through the user, the IdP does not know the request message has not been modified. If the IdP assumes the two identifiers are bound, then a malicious user can pretend to be a different user from the same IdP to the RP. This presumes the IdP is using an IdP identifier and the RP is using an RP identifier and the binding is assumed by sending both. Therefore, the IdP MUST make sure the two identifiers are linked, so sending both is redundant for the IdP. The relying party knows both identifiers from doing discovery, and it must check to make sure they match what is in the assertion. Since the relying party MUST make sure it matches, the IdP doesn't have to. I would say that the IdP SHOULD check to make sure it's valid, but it's not strictly required. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
PROPOSAL: Bare Request
Motivating Use Case: When an RP is storing attributes at an IdP and does not want to authenticate the user, the RP may want the user to remain at the IdP. Other extensions may want similar functionality Proposal: A missing openid.return_to is NOT an error. Affects: 5.2.3 10.1 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Discussion: RP Yadis URL?
Currently there is no method for the IdP to learn anything about the RP. As a path for extensibility, would anyone have a problem with having an optional parameter in the AuthN Request for the location of the RP's Yadis document? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Auth Age clarified
Clarification: auth_age allows an RP to specify how long it has been since the IdP has authenticated the user. The use case of this is for sites that have different auth_age requirements for different sections of the site. For example, amazon.com lets me browse around the site with an fairly old auth_age, but when I go to purchase, amazon wants to make sure it is still me, and asks me for my password again. With OpenID, the IdP is prompting the user for their password on behalf of the RP, so in order for amazon to have the same functionality with OpenID, amazon needs to be able to differentiate between an authn request that with a long auth_age and one with a zero auth_age. Note that this is only a request from the RP. It is not a security requirement. I can have my browser autocomplete my password at amazon.com, so prompting me for my password again when I checkout provides no assurance it is still me at the browser, but it is *my* choice to do that, ie. the user's choice on how to deal with the prompt. Amazon is giving me the choice to have higher security on checkout then on browsing the site. In other words, Amazon is giving the IdP context about the authn request. This is similar to the RP stating that a field in a form is required. There is nothing that forces the user to type anything in, it is a request. This is different then an RP requesting strong authentication. This is a security request, and the RP must trust whoever is making the claim that strong authentication was performed. Auth spec vs Extension Although this functionality could be in an extension, it seems too be a lot of overhead for a single parameter. This is the AuthN spec after all, and auth_age is a parameter around what the IdP does wrt. AuthN. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
openid.identifier vs openid.identity
Given that the spec uses the word identifier throughout, it would make sense that the parameter would be called that. Perhaps in changing what the parameter contains, we can rename it, and keep openid.identity for backward compatibility? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
