RE: Auth 2.0 Extensions: Namespace Prefixes
But it seems superflous: Since you cannot depend on args to be ordered[1], you'll still need to iterate and match prefix to values. Also, any change adds complexity: You'll need to specify semantics to what happens if the list of extensions is not there, or if it is incorrect, or if you use extensions without declared namespaces, etc. But if it still is needed, I'd propose, since the list of extensions is meta info, it should itself be an extension. openid.ns.ext=some:fixed:uri openid.ext.namespaces=ns1,ns2,ns3 openid.ns1.foo=... openid.ns1.bar=... openid.ns2.foo=... This makes processing cleaner and it also makes it possible for future specification of extensional behavior (sounds very Sartre ;) openid.ext.policy=... openid.ext.foo=... -Hans [1] I'm looking at you HttpServletRequest.getParameterMap() -Original Message- From: [EMAIL PROTECTED] on behalf of Recordon, David Sent: Tue 6/5/2007 8:00 AM To: Martin Atkins; specs@openid.net Subject: 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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Auth 2.0 Extensions: Namespace Prefixes
On 5-Jun-07, at 8:53 AM, Granqvist, Hans wrote: But it seems superflous: Since you cannot depend on args to be ordered[1], you'll still need to iterate and match prefix to values. Martin's proposal seems like a minor improvement to me - iterating thorough openid.ns.* or splitting the value of openid.extensions and then iterating through the result seems roughly equivalent. Fair enough. I guess the question is: Is the cost of semantical additions (as I outlined) worth such a minor improvement in processing? -Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Specifying identifier recycling
So I ask again - does anyone see any issues with the fragments being used like this: http://openid.net/pipermail/specs/2007-May/001767.html Seems reasonable in essence. But it adds complexity and removes some immediacy of URL identifiers-as-is. Do fragments need special handling just to handle id recycling risks? I'm probably missing some context, but can't the issuing OP make sure to issue unique IDs, like http://example.com/user1234 instead of http://example.com/user#1234 ? Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: encoding newlines in attribute values
Hi Johnny, Just so we're all on the same page: Can you post a link to the referenced proposal? Thanks, Hans -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johnny Bufu Sent: Friday, April 27, 2007 3:46 PM To: OpenID specs list Subject: Re: encoding newlines in attribute values On 20-Apr-07, at 11:18 AM, Dick Hardt wrote: To expand on that and include Mark Wahl's proposal about locale encoding[1] in a standard way for attributes so that the libraries can do the right thing 99% of the time. I would propose that AX data have a default encoding that can be overrode by the attribute metadata. The default would be: URL encoding for text data escape sequence for locale using mechanism in RFC 3866 escape sequence to indicate binary data that is then base64 encoded Does this work for everyone? If there are no issues, I'd like to summarize it in the spec so that: - a default encoding is defined as described above - attribute specific encodings can be used, and their presence is signaled with an escape sequence similar to the ones used in Mark's language tags proposal. The default encoding would then be applied only when a attribute- specific encoding was not used. Agreed? 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
On OpenID 2.0
All, Over the last several weeks, I have tried [1][2] to ask the list to clarify into the state of the current OpenID 2.0 specification draft. There seems to be little interest in finalizing 2.0. The current draft 11 is over three months old. Draft 5 dates back over ten months, and who knows when draft 1 was penned! Let's try to see if we can figure out something here: * Do you see anything *negative* around finalizing 2.0? * With 2.0 RP implementations almost non-existent in the field after more than ten months of spec work -- is there even a need for 2.0? * If you have a RP: why are you waiting with implementing 2.0? Is 1.1 good enough? Are you waiting for the spec to be final? Do security concerns hold you back? While I appreciate the free flowing spirit of the OpenID spec work, I do believe there now is an acute need for timelines and imposed processes: Deadlines beget progress. Interop events ensure interoperability. And so on... Anyone agree/disagree? Let's hear it. Thanks, Hans [1] http://openid.net/pipermail/specs/2007-March/001389.html [2] http://openid.net/pipermail/general/2007-April/002275.html ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: encoding newlines in attribute values
Cool, thanks! -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Monday, April 30, 2007 9:51 AM To: Granqvist, Hans Cc: OpenID specs list Subject: Re: encoding newlines in attribute values Hans, On 30-Apr-07, at 9:22 AM, Granqvist, Hans wrote: Just so we're all on the same page: Can you post a link to the referenced proposal? Mark has announced it here on the list: http://openid.net/pipermail/specs/2007-April/001630.html Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Java RP
Hi Gabe, Unfortunately joid doesn't support XRIs --- lack of resources/time. If you or anyone else want to work on a patch with (or without) me, let me know and we'll make it happen! -Hans -Original Message- From: Gabe Wachob [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 11, 2007 10:35 AM To: Granqvist, Hans; 'Dick Hardt'; 'McGovern, James F ((HTSC, IT))' Cc: specs@openid.net Subject: RE: Java RP Hans- I didn't see XRI support in joid - was I mistaken? -Gabe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Granqvist, Hans Sent: Wednesday, April 11, 2007 9:31 AM To: Dick Hardt; McGovern, James F ((HTSC, IT)) Cc: specs@openid.net Subject: RE: Java RP Or this library (also ASF 2.0) for creating both OP and RP, which follows a slightly different API approach: http://code.google.com/p/joid (If you're coming to JavaOne in May, there will be a presentation on it.) -Hans -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Wednesday, April 11, 2007 9:15 AM To: McGovern, James F ((HTSC, IT)) Cc: specs@openid.net Subject: Re: Java RP The OpenID4Java library is licensed under Apache 2.0 -- a very commercial friendly license source development here: http://code.google.com/p/openid4java/source package here: http://code.sxip.com/openid4java/ -- Dick On 11-Apr-07, at 6:37 AM, McGovern, James F ((HTSC, IT)) wrote: I have been thinking that the best contribution I could make to OpenID would be the first enterprise that deploys OpenID into production. OpenID needs more press than it is receiving and by showing that a large Fortune enterprise is using would be a big win. I do however have one constraint in that the absolute fastest way of accomplishing deployment would be for me to identify a 100% unrestricted open source Java RP code base that I could incorporate. The notion of going through any form of procurement would not allow me to accomplish this goal. Is anyone aware of the existence of a 100% unrestricted open source Java RP code base? ** *** 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 ___ 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: Version 2.0 soon final?
Yes, that's what I meant. Final release as in done. Sorry for the confusion . . . From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pat Patterson Sent: Monday, March 26, 2007 12:47 PM To: Dick Hardt Cc: specs@openid.net Subject: Re: Version 2.0 soon final? Here at Sun (and, I guess elsewhere), it means 'First Customer Ship', but I think we use 'Revenue Release' (RR) instead these days. Cheers, Pat Dick Hardt wrote: On 26-Mar-07, at 12:22 PM, Josh Hoyt wrote: On 3/20/07, Granqvist, Hans [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: OpenID 2.0 has been cooking for quite a while. When will 2.0 be FCS? What does FCS [1] mean? Josh 1. http://en.wikipedia.org/wiki/FCS Future Combat Systems? http://en.wikipedia.org/wiki/Future_Combat_Systems ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Pat Patterson - [EMAIL PROTECTED] Federation Architect, Sun Microsystems, Inc. http://blogs.sun.com/superpat ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: modulus and generator optional in association requests
How did you / others deal with this? There are quite a few ... Same way that you do/propose -- by using the default values if they are not present. -Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Proposal: An anti-phishing compromise
Josh, thanks for posting! See my comments inline -Hans ... Other relevant issues: ... * 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) Is that entirely true? There is a flow in the OpenID protocol that is hardly ever used, the association flow, that can be used. 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. Benefits The proposal is trivial implement, it acknowledges that But it's not trivial to deploy! Since the proposed solution fundamentally changes the basic authentication payload, every single implementation would have to change. Drawbacks - It may be tricky to define what is meant by non-phishable. And any such definition would probably change over time, too. ... My overall problem is that I don't see how your proposal really solves phishing. Am I crazy? (It has happened before ;) Perhaps you're only concerned with the OP/RP relation? Your proposal is based on the OP adding an extra field into its authentication response, but in a phishing scenario, this OP would never even be involved in the authentication step. 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. This information may contain the phishing strength field you define above, but it can also contain something like a security profiles. (Yes, here I go again ;) It just seems to make sense to do it this way. 1. OPs that want to remain like today, can do so by accepting non-associationed authentication requests, or by not requiring the meta-information in the association request. 2. OPs that want to provide a stronger user story would require the assoc step + meta-info. The OP now becomes its own gate keeper: only good enough RP's will have acceptable profiles (perhaps cryptographically signed by a 'trusted 3rd party', or asserted via other reputational mechanisms), and therefore these RPs are the only ones that can authenticate. 3. in the same vein, the RP would only redirect to acceptable OPs. The RP decides what is an acceptable OP just as the OP decides what is an acceptable RP. 4. the user would still be out in the cold unless it is impossible to log in as a side-effect of an authentication step (as previously discussed on the list). Perhaps that entire 'log in when authenticating' flow should be stricken from the spec unless user's explicitly desires that behavior via some mechanism (like added params to the URL -- ugly, or a checkbox next to the URL input field -- questionable). Anyway, just my thoughts. Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Key Discovery In DTP Draft 3
+1. A lot of thought went into the KeyInfo element design. And the spec can define a valid subset of KeyInfos, too, if needed. -Original Message- From: Recordon, David [mailto:[EMAIL PROTECTED] Sent: Friday, January 05, 2007 09:50 AM Pacific Standard Time To: Grant Monroe Cc: specs@openid.net Subject: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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: OpenID.net Service Type Namespaces
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
RE: Summarizing Where We're At
I want to avoid the wait-I-thought-we-decided-something-else or ahh-yes-seems-we-forgot-it-had-an-impact-there delays . . . Spec work gain tremendously by unambiguous up-front definitions of what *exactly* is voted on. A good way to do this is to force the vote to be on an explicit diff against current draft. What ye say? Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Delegation discussion summary
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 unless a portable identifier is used. Both portable and IdP-specific
RE: Delegation discussion summary
Makes sense, but do you *have* to put delegation info in an XRDS document? I'd like to think if I were to use an RP that I trust not to 'collude' with the IDP, there would be no reason for the IDP to know potential delegation? That gives me true identity portability and an open choice of IDPs. Once an IDP knows of and starts tracking my vanity identifier (bound to happen) I cannot easily give up that identifier. -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Friday, October 13, 2006 9:11 AM To: Granqvist, Hans; 'Josh Hoyt'; specs@openid.net Subject: RE: Delegation discussion summary Hans, This has come up a few times and the mapping between the portable identifier and the IdP-specific identifier is available in public XRDS documents. So there's no point in trying to hide that information from the IdP -- and it may even be misleading to suggest to end-users that they could try to do so. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Granqvist, Hans Sent: Friday, October 13, 2006 8:52 AM To: Josh Hoyt; specs@openid.net Subject: RE: Delegation discussion summary 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
RE: Identifier portability: the fundamental issue
To achieve identifier portability in OpenID, it MUST be possible for the RP and the IdP to identify the user using two different identifiers: an identifier by which the RP knows the user (the portable identifier), and an identifier by which the IdP knows the user (the IdP-specific identifier). There is no reason why the idp MUST require to know both identifiers for identifier portability to be possible in the system. I would submit that if this postulate is true, then OpenID Authentication 2.0 requires two identifier parameters because if the protocol only allows sending one, then: 1) If the RP sends the IdP-specific identifier, the RP must keep state to maintain mapping to the portable identifier (bad), and Why is it so bad for an RP to be required to maintain such state? (Besides, an RP could advertise whether it is willing to keep that state, and the user would decide what to do.) Keeping such state seems a very slight inconvenience for a much greater goal: true portability of my identifiers. What the idp doesn't know, it cannot take away. ... ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Re[2]: Strong Authencation (was [PROPOSAL] authentication age
I think the 2.0 spec extension mechanism could handle signed credentials. For example, credentials=s where s is of a (string) format that contains a type + signature, say credentials=OATHVIP:WW91IGhhZCB0byBjaGVjaywgZGlkbid0IHlvdT8gOyk= The format could also further specify mechanism types, signer identity, and algorithm(s) used if those are not part of the definition of 'credentials'. Hans -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drummond Reed Sent: Thursday, October 05, 2006 2:26 PM To: 'Chris Drake' Cc: specs@openid.net Subject: RE: Re[2]: Strong Authencation (was [PROPOSAL] authentication age Chris, Great examples. Signed credentials makes lots of sense. OpenID AuthN 2.0 doesn't handle them yet but I can completely understand them in the roadmap. =Drummond -Original Message- From: Chris Drake [mailto:[EMAIL PROTECTED] Sent: Thursday, October 05, 2006 10:51 AM To: Drummond Reed Cc: specs@openid.net Subject: Re[2]: Strong Authencation (was [PROPOSAL] authentication age Hi Drummond, Example1: RSA would provide a signed response indicating that the user correctly entered the SecurID token code. Example2: The RP would have the public key of the company that supplies the fingerprint scanning hardware (although some extra thought as to how a fingerprint ultimately matches to an Identity is required, which will need an entirely different information flow to Example1). Is Dick a vendor himself? he no doubt knows other ways. Kind Regards, Chris Drake, =1id.com Friday, October 6, 2006, 3:19:44 AM, you wrote: DR Dick, DR You say, The strong authentication will be supplied by a vendor DR that has DR been certified to provide standardized levels of authentication. The DR IdP will often NOT be the strong auth vendor. DR Can you explain how this might work, i.e., how can the RP have a DR relationship directly with the strong auth vendor and not the IdP? DR Would the DR IdP be outsourcing authentication to the strong auth vendor? In DR which case, DR isn't the strong auth vendor the IdP? DR =Drummond DR -Original Message- DR From: [EMAIL PROTECTED] DR [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt DR Sent: Thursday, October 05, 2006 9:36 AM DR To: Gabe Wachob DR Cc: specs@openid.net DR Subject: Strong Authencation (was [PROPOSAL] authentication age DR The vision I have is that strong authentication to your IdP will be DR common in the future. DR The strong authentication will be supplied by a vendor that has been DR certified to provide standardized levels of authentication. The IdP DR will often NOT be the strong auth vendor. DR The RP will have a trust relationship with the vendor, likely DR through a vendor consortium that delegates to vendors that their DR product is certified, ie. the RP will not need to trust each vendor, DR just the certification body. DR I would hope that OpenID can be extended over time to be able to DR move around these types of strong auth assertions. DR -- Dick DR On 4-Oct-06, at 8:41 PM, Gabe Wachob wrote: Chris- As someone who has recently come from working in the financial sector (Visa), its clear that OpenID is NOT intended for authentication where the *relying party* cares about how the authentication is performed. At places like Visa and for home banking, this means that OpenID, without something more, is clearly a non-starter. These relying parties want to know exactly how their users are being authenticated because their business is all about risk management and creating business opportunities around very good knowledge of the risk profile of each transaction type. That all being said, I believe it should be possible to layer on OpenID a form of IDP control such that a relying party can require a certain class or group of IDPs be used when presenting authentication assertions to them. The actual *policy* for how these IDPs are approved is probably orthogonal to the protocol spec, but secure identification of those IDPs (relative to some trust root, etc) could probably be made into an extension usable for those parties who want it. My guess is that culturally, most people involved in OpenID have *not* been interested in addressing these concerns. However, expectations need to be better managed around these sort of relying-party cares scenarios, because its not obvious without actually reading the specs themselves... -Gabe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Drake Sent: Wednesday, October 04, 2006 8:26 PM To: Kevin Turner Cc: specs@openid.net Subject: Re[2]: [PROPOSAL] authentication age Hi Kevin, Sounds like you're leaning towards a root authority for IdPs who can
RE: Request for comments: Sorting fields in signature generation-Call for votes
Behavior needs to be specified before it can be recommended. So the spec MUST specify how to deal with the multiple parameters before it can set the use thereof as NOT RECOMMENDED. Hans -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Wednesday, September 27, 2006 1:13 PM To: Josh Hoyt; Marius Scurtescu; Brad Fitzpatrick Cc: specs@openid.net Subject: RE: Request for comments: Sorting fields in signature generation-Call for votes I don't think multiple parameters with the same name should be completely disallowed, rather that section 7.1 should strongly discourage their use. I agree that from the core authentication standpoint they aren't needed today, though do understand that in the future there may be a compelling use case for them. I believe the simplicity that is offered from not supporting them out weighs the benefit of form handling with existing forms. So +1 to tightening up section 7.1, but -1 to it specifically allowing multiple parameters with the same name. I believe the wording should be such that it is strongly NOT RECOMMENDED that extensions to OpenID Authentication utilize GET or POST parameters with the same name. Brad, thoughts? --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Wednesday, September 27, 2006 12:20 PM To: Marius Scurtescu Cc: specs@openid.net Subject: Re: Request for comments: Sorting fields in signature generation -Call for votes On 9/27/06, Marius Scurtescu [EMAIL PROTECTED] wrote: please keep in mind that we are not asking for some fancy new technology or feature, just conformance with a very basic an wide spread convention of handling parameters in HTTP/HTML. As Kevin pointed out, we are not working on the HTTP/HTML form processing specification. We are working on an authentication protocol. Restricting the protocol to forbid multiple parameters with the same name does not break conformance with anything. I think that we have discussed the majority of the technical issues regarding multiple parameters with the same name. I could respond to your individual points, but I don't think that would get us any closer to agreement. Can we get +1/-1 on multiple parameters with the same name from people without @sxip.com or @janrain.com e-mail addresses? Clearly, we (JanRain) are -1. 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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Removing SIGNALL From Draft 10
+1 on removing SIGNALL There are significant security risks with signing unseen data, which SIGNALL in effect allows. Such chosen plaintext attacks can be devastating to protocols. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Friday, September 29, 2006 11:39 AM To: specs@openid.net Subject: [PROPOSAL] Removing SIGNALL From Draft 10 While I know this was added in draft 9, I'd like to readdress it as I'm concerned from a technical perspective. My understanding of the motivation was to allow a Relying Party pass arbitrary key/value pairs to an IdP and have them passed back in the signature. I believe that this, minus the parameters in the response being signed, can be achieved via the return_to parameter. This is a URL generated by the Relying Party for where the Identity Provider should redirect the End User upon authentication. It thus can be used by the Relying Party to maintain state between requests. My concerns: 1. There is no manifest for the fields that get signed, which makes it more vulnerable to certain kinds of attacks, if weaknesses are found in the MAC generation algorithm. This could be corrected by using a signed list that used full keys instead of leaving off the openid., but see (2). 2. The entire query becomes part of the OpenID message, rather than just the prefixed fields. As I remember it, the original motivation for using prefixed parameters was to avoid collision with existing parameters of any applications. Signing these parameters mixes them in with the authentication request or response. One of the nice things about OpenID 1.x is that it's really clear which parts of the HTTP messages are OpenID-specific; I'd like to preserve that. Thoughts? --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: Request for comments: Sorting fields in signature generation
I think the real topic of this discussion is whether or not multiple parameters with the same name should be allowed by the specification. I'd support the motion of not doing that. Johannes, just to clarify, are you against allowing multiple same-name params? Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Request for comments: Sorting fields in signature generation
Well, then +1 to disallowing such multiplicity! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Tuesday, September 26, 2006 4:15 PM To: Granqvist, Hans Cc: Barry Ferg; specs@openid.net Subject: Re: Request for comments: Sorting fields in signature generation On 9/26/06, Granqvist, Hans [EMAIL PROTECTED] wrote: Does this problem exist if SIGNALL goes away? If there are multiple parameters with the same name, the problem is there, with or without SIGNALL, unfortunately. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
