OpenID/OAuth hybrid - discovery
Section 5 Discovery of the OpenID/OAuth hybrid draft spec says xrd:Typehttp://specs.openid.net/extensions/oauth/1.0/xrd:Type should appear in the XRDS discovery document to indicate support for the protocol. This doesn't seem to be the right way around. Discovery is performed on a user's OpenID identifier. It does not make sense for a user to indicate if an OP supports the hybrid protocol. Additionally, support cannot be indicated by users who use an HTML page for their OpenID identifier (with an link rel=openid2.provider href=.../ element). An OP could indicate that it supports the hybrid protocol in its own XRDS file, assuming all users use directed identity and they all use the same OP XRDS file. I hope we don't have to hardwire these assumptions into the hybrid spec. Even in this case, however, indicating hybrid support at the OP is not of much use if the RP/consumer cannot tell which protected resources are covered. For example, adding the hybrid indicator to the Yahoo OP XRDS file http://open.login.yahooapis.com/openid20/www.yahoo.com/xrds does not tell an app if it can use the hybrid protocol to access: * Yahoo email address book (probably); * Flickr photos (maybe?, it is owned by Yahoo); * Microsoft hotmail (perhaps not currently, but a Yahoo/Microsoft merger was discussed earlier this year); * Picassa photos (presumably not, as it is owned by Google). Discovery could work if the metadata for the OAuth Service Provider indicated it supports the hybrid protocol with a specific OP. [My preferred way to indicate this would be: a request to a protected resource receiving a 401 Unauthenticated response with a WWW-Authenticate HTTP header that included the URL of the OP. If that OP URL matches the OP found from OpenID discovery on the user's OpenID identifier then the app can use the hybrid protocol.] James Manger [EMAIL PROTECTED] Identity and security team — Chief Technology Office — Telstra ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: OpenID/OAuth hybrid - discovery
Breno, The fact that the OP indicates support for hybrid has nothing to do with directed identity, of whether or not they use the same XRDS file. What is section 5 Discovery for? Is it supposed to allow an app (after finding a user's OP) to make additional requests to get the OP's metadata to see if it supports the hybrid protocol? Learning just that an OP supports the hybrid protocol (without any indication of the associated protected resources) seems to be of minimal value. James Manger [EMAIL PROTECTED] Identity and security team — Chief Technology Office — Telstra ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID/Oauth hybrid
How much special knowledge about the OP/SP is an app expected to have to use the OpenID/OAuth hybrid protocol? [and some performance issues at the end] A common case might be an app built to enhance one specific service. It is probably realistic to assume such an app is registered with the SP, and has hardwired knowledge about its OAuth URIs, scopes, signing modes etc. Another case is an app that dynamically learns who a user's OP is (eg from OpenID discovery) and which SP the user uses for the service of interest (perhaps from the same OpenID discovery). The app notices that the OP and SP are the same (how?) and that they support the hybrid protocol (how?). This app understands OpenID, OAuth, hybrid, and the type of service of interest -- but has no special knowledge about this user's specific OP/SP. The first case may cover many immediate pain points, particularly as OpenID and OAuth are in their infancy. However, a standard would be much more useful for the whole community and in the medium term if it supported the second case as well. Even if the discovery aspects are not solved immediately, the hybrid protocol should not *preclude* apps without SP-specific knowledge once discovery mechanisms emerge. The current hybrid draft adds openid.oauth.consumer and openid.oauth.scope fields to an OpenID request. The former forces the app to be pre-registered. The latter requires the app to know about the SP's specific scopes. It seems possible that more parameters might be required in future: perhaps permissions (eg read/write), or lifetime (once-off, for 24 hours, forever). All these parameters seem to tightly couple the app to the SP. An alternative is to add one opaque handle to the OpenID request: a request token. To add a new scope, offer a new permission, support a new lifetime, etc an SP can offer a new URI for getting the new request tokens. As far as the app code is concerned it is just a URI, like any other URI. It doesn't necessarily need code that understands permissions, or scopes, or lifetimes etc. Breno de Medeiros said the initial OAuth request for a token adds a (probably unacceptable) redundant server-to-server call for *every* authentication request. It may be better for performance to omit the request AFTER the redirect, instead of the request BEFORE the redirect. OAuth involves: 1. get request token 2. redirect user to do authorization 3. swap request token for access token 4. do stuff Step 3 was added to OAuth to support apps that could not launch/redirect-to a browser. Such apps need the user to manually type in a token, which needs to be short to be human-friendly. Step 3 allows a short token to be exchanged for a longer one that can encode lots of state so the service can operate in a stateless (scalable) manner. Step 3 was kept for all OAuth apps (not just those that could not launch/redirect a browser) to keep the spec simple. The hybrid protocol could save a request/response pair by dropping step 3 (or make it optional so apps that cannot launch/redirect-to a browser can use it). The initial request for a request token (step 1) does not have to affect the user experience -- as it can be done in advance. An app could get request tokens in the background and cache them until one is needed for a hybrid auth/authz redirect. Keeping step 1 but omitting step 3 means the access token needs to be returned in the authentication/authorization response. The request token secret can be used instead of getting a new access token secret. The hybrid spec says [in section 3 Purpose] For security reasons, the OAuth access token is not returned in the URL. It is not clear what these security reasons are. I suspect they only apply because the hybrid protocol had dropped the token secret from step 1. [It might not even be necessary to perform step 1 for *every* authentication request. If the returned token simply encodes the scope and/or consumer identity, then the service could set a Cache-Control header indicating that the token can be reused for, say, any authentication requests in the next day (I will have to think about any security implications). Alternatively define a way for an app to get a batch of request tokens in one go.] James Manger [EMAIL PROTECTED] Identity and security team — Chief Technology Office — Telstra ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: OpenID/Oauth hybrid
Breno, Thanks for your responses. The scopes are needed for the approval page to be rendered. The whole thing is meaningless otherwise I absolutely agree that the auth/authz redirect needs to know what actions are being authorized, ie the scope. I don't want to eliminate the scope, just use a single opaque token to represent it -- regardless of which aspects any specific SP needs the scope to encompass [app id, resources, permissions, lifetimes...]. The token comes from a URI, which is what really represents the scope. You mean that the app has to understand all of the above, but will use that knowledge during the discovery process, rather than authorization *Something* has to understand all of the above [scope, permissions, lifetime...] -- but it does not have to be the app. It can be the app. It can be the user. It can be another system that provides discovery details. Perhaps it can be a hyperlink on a web page. The app just has a URI and it flows from there. If that [discovery] effort is successful, I do not think any of these issues are intractable. It is conceivable that discovery can provide 'scope' strings, and even 'consumer' values for unregistered apps -- but that does not feel like it fits well with the web architecture. It feels unnecessarily complicated and OAuth-specific. I can image discovery providing: A URI for my address book; A URI for my calendar; A URI for my photos; A separate URI for my photos of a particular conference; I am concerned that with the current hybrid draft, discovery will have to define 'scope' strings etc in addition to a URI to access a service. I doubt generic web discovery mechanisms will offer that. James Manger [EMAIL PROTECTED] Identity and security team — Chief Technology Office — Telstra ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Dirk, Allen, Brian, etc How about sending an ‘unauthorized request token’ with the OpenID authentication request, instead of a scope or a consumer key? A Service Provider can choose to encode the consumer key or scope into the request token when issuing it if they need those details when interacting with the user. From the OAuth perspective there would be minimal change to the protocol. Instead of redirecting the user to the authorization URL (after adding the token), the user is redirected to the OP URL (after adding the token). That makes it easier to be confident that the hybrid model does not introduce new security weaknesses. Ideally, an app would attempt to access a protected resource at an SP and get: * A 401 Unauthenticated response from the SP; with * A “WWW-Authenticate: OAuth” header; with * A parameter providing the authorization URL; and * Another parameter with the OP URL (when OpenID/OAuth hybrid was supported). If the app supports the hybrid mode, and the SP has indicated it supports the hybrid mode by including an OP URL in a 401 response, and the user’s OpenID identifier resolves (via discovery) to the same OP, then the app can trigger the hybrid auth/authz action. James Manger ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Non-interactive logins
Hi Anders, There has been some work on this important issue, though it seems to have been dormant for a while. There seem to be two proposals (by Martin Atkins) using OpenID as an HTTP authentication mechanism. It is suitable for non-browser, non-interactive use cases. http://wiki.openid.net/OpenIDHTTPAuth http://wiki.openid.net/OpenID_HTTP_Authentication I really like the idea of this basic flow: 1. RP indicates it supports OpenID with WWW-Authenticate: OpenID header; 2. App interacts with the app's OP; 2. App sends OpenID authentication response to RP in Authorization header; 3. RP performs discovery; 4. RP does direct verification with OP. App --GET xxx-- RP --401 WWW-Authenticate: OpenID realm=...-- App OP [if necessary] App --GET xxx Authorization: OpenID opened-auth-request-stuff-- RP RP --GET claimed_id-- --discovery XRDS/HTML-- RP --POST ...openid.mode=check_authentication-- OP --is_valid=true-- App --200 content-- ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Problems with OpenID and TAG httpRange-14
As confusing as HTTP redirect semantics might be, I am confident that you will not find anyone that deliberately chooses to return a 303 See Other without explicitly wanting to keep the original URL as the identity and the new URL as merely a (stable, cachable) location for the current response (eg current OP details). I am confident this will be true for any web content, not just OpenID. [Aside: Browsers displaying the new URL in the address bar after a 303 See Other is not a counter-example. The new URL is the address of the displayed response. It is NOT the address that will be reused if the original request (eg an HTML form submission) is retried.] The ability to serve discovery details from a location that is different from the claimed_id is desired functionality: 1* You can achieve it using X-XRDS-Location (HTTP header or meta element), but only if you deliver other content (eg HTML) at the claimed_id; 2* You can achieve it using an i-name (by the abstract nature of those ids and the various synonyms explicitly defined for those ids); 3* You can achieve it via directed identity if your OP cooperates, and with a very extra request/response pairs; 4* You CANNOT achieve it using standard HTTP (with 303 See Other). The question is whether OpenID wants to bother supporting #4. In adding support for XRI/XRDS/i-names OpenID 2.0 made HTTP URIs somewhat second-class citizens by offering some functionality only when XRI/XRDS is used, even when sensible HTTP mechanisms were also available. Two examples are: supporting X-XRDS-Location but not 303 See Other; and indicating an OP Identifier with a special XRDS Type, but not with a special openid2.identifier value. For a true-believer in i-names, not offering an HTTP-way for some functionality is not important (perhaps even helpful for promoting i-names). For a true-believer in HTTP (less enthused by i-names), the lack of an HTTP-way is a problem. Kevin Turner said: Amend the specification to say: A request for an OpenID Identifier SHALL NOT issue a 303 response. Thankyou Kevin, for a lateral solution. It is not the fix I want (proper HTTP-style support for 303 See Other), but at least it explicitly tells people that OpenID 2 does not support 303 semantics. That should allow proper 303 support to be added later without big backward compatibility issues. [Aside: In practice, OpenID RP libraries would probably not be changed to explicitly reject 303s -- particularly as your major argument is that that sort of change makes the code too complex. Rejecting or interpreting 303s both require explicitly handling redirect codes, as opposed to setting the follow redirects automatically option of the HTTP client library.] Objections to proper support for 303s don't say the proposal is wrong. They just imply it is not worth the effort: code too complex, do not have to obey HTTP, work arounds available, 2.0 is finished. Not surprisingly, these judgements are not convincing to some HTTP true-believers. Perhaps I will add a note to the OpenID 2.0 errata page stating HTTP 303 See Other semantics are not currently supported so they should be avoided when hosting OpenIDs. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
openid:Delegate undefined namespace
Section 14.2.1 Relying Parties (discussing compatibility with OpenID 1.1) says: the end user's OP-Local Identifier appears in the openid:Delegate tag However, the namespace URI associated with the openid namespace prefix is not defined. I guess it should be http://openid.net/xmlns/1.0;, which needs to be mentioned in the spec. Change openid:Delegate in the 2nd dot point in 14.2.1 to Delegate xmlns='http://openid.net/xmlns/1.0' ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
[OpenID] HTML discovery for OP Identifier
HTML discovery should support OP Identifiers. It is easy. If an OP-Local Identifier with the special value http://specs.openid.net/auth/2.0/identifier_select; is discovered, then the Claimed Identifier is actually an OP Identifier. The spec is also confusing since “Claimed Identifier” and “openid.claimed_id” are not always the same. The spec says you always get a “Claimed Identifier” from the normalization phase [§7.2 point 4], but contradicts that two sections later [§7.3.1] saying sometimes there is no “Claimed Identifier” if it turns out to be an “OP Identifier”, but the openid.claimed_id field is still sent just with a another (predefined) value. Q. Is there a good reason for sending http://specs.openid.net/auth/2.0/identifier_select; in two fields, instead of sending the OP Identifier in openid.claimed_id? That is, why not always send the normalized User-Supplied identifier in openid.claimed_id, regardless of the OP-Local Identifier? I suggest replacing §7.3.1. Discovered Information with the following: The Relying Party starts the discovery process with a Claimed Identifier and, upon successful completion, will have one or more sets of the following information (see the Terminology section for definitions). If more than one set of the following information has been discovered, the precedence rules defined in [XRI_Resolution_2.0] are to be applied. * OP Endpoint URL * Protocol Version * Claimed Identifier * (optional) OP-Local Identifier The Claimed Identifier may have changed during discovery if it was an XRI [see §7.3.2.3]. The Claimed Identifier will change during authentication if the OP-Local Identifier is present and has the special value http://specs.openid.net/auth/2.0/identifier_select;. In this case the Claimed Identifier in the authentication request is actually an OP Identifier. A different Claimed Identifier will be returned in the authentication response. Discovery will have to be performed again on the new Claimed Identifier once it is received [see §11.2]. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
HMAC-256 vs HMAC-SHA256 for openid.assoc_type
Is the correct value for the openid.assoc_type parameter really “HMAC-256”, and not “HMAC-SHA256”? That is what the spec (draft 12) says, though it is somewhat counter-intuitive given the algorithm is named “HMAC-SHA256” and the other algorithm “HMAC-SHA1” uses the same string for the algorithm name and assoc_type value. Googling for assoc_type=HMAC-SHA256 finds 5 results (from 3 code bases?). Googling for assoc_type=HMAC-256 finds none. http://openid.net/specs/openid-authentication-2_0-12.html#assoc_types “8.3.2. HMAC-SHA256 An association of type HMAC-256 uses the HMAC-SHA256 (Signature Algorithms) signature algorithm.” ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: HMAC-256 vs HMAC-SHA256 for openid.assoc_type
It was “HMAC-SHA256” in draft 9 (10 Sep 2007), but had changed to “HMAC-256” in draft 10 (13 Oct 2007). The change is looking more like a typo. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] identify RP when it gets OpenID URL
I am keen for the RP to identify itself when it performs discovery – and I would love this feature to be in 2.0 before it is finalized. The proposal is very simple (to describe and to implement): RPs add a “From:” HTTP header field to HTTP requests made during the discovery phase. The underlying premise is that a user has many varied user-RP relationships, and it is easiest if the same OpenID URL can be used to access them all. The issue is how to support the varied relationships. Some OPs will support some variations, but no OP can support all possible variations (many are user-specific). Identifying the RP during discovery enhances the ability to choose the appropriate OP for a specific user-RP relationship. The need for this feature can be seen in the PAPE draft (§3 Advertising Supported Policies) and OpenID 2.0 draft (§12 Extensions). They support different OPs when authenticating to different RPs - but with very limited options, and with the RP in control of the choice. The user (via the server hosting their OpenID URL) should also be in control. http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-02.html#advertising http://openid.net/specs/openid-authentication-2_0-12.html#extensions Both specify how a Yadis document can list multiple OPs, each associated with different OpenID protocol versions, understanding different OpenID extensions, and supporting different authentication policies. These details “aide in the process of a RP selecting which OP they wish to interact with”. The appropriate OP can only be chosen **by the RP** based on a very limited set of pre-defined xrd:Type URIs. When that works… great. When it doesn’t, the site hosting the OpenID URL should be able to choose the appropriate OP based on the RP’s identity. For that it needs the RP identity during discovery, hence the “From:” HTTP request header. Previously mentioned use cases: Alice wants to use a single OpenID URL and -- 1. She wants to use different OPs when logging in to different RPs. 2. An OP is not accessible to particular RPs (eg an internal company OP is not accessible by RPs on the Internet). 3. Different RPs whitelist different (non-overlapping) sets of OPs. 4. A particular RP requires PAPE support, which only Alice’s non-preferred OP supports. From: Manger, James H Sent: Wednesday, 17 October 2007 12:59 PM To: 'specs@openid.net' Subject: [OpenID] identify RP when it gets OpenID URL It can be useful to know who the Relying Party (RP) is during the discovery phase. That is, the RP should state their identify when they are looking up a user’s OpenID URL (Claimed Identifier). Use case: Alice wants to use different OPs for different RPs, while keeping the same URL (eg http://alice.example.net/). For instance, when logging into a service hosting her backups she wants to use an OP that requires a one-time password from a hardware token for each access. However, when leaving comments on blogs Alice wants to authenticate using an OP that only requires a password and uses a persistent cookie so she only has to log in once a day. Problem: Only one OP can be specified with a link rel=openid2.provider…/ element or in a Yadis document. [A Yadis document may be able to list many OPs, but I don’t think there is any mechanism for the RP to pick the right one.] Solution: The RP could include a From HTTP header when performing discovery. Instead of serving a static HTML page (or Yadis document) at http://alice.example.net/, the page could be dynamically generated based on the value of the From header. Suggested text for the authentication spec (draft 12): Add the following paragraph at the end of section 7.3 Discovery: “The Relying Party MUST include a From HTTP header field in each HTTP request made during discovery. The From field holds an email address for the RP (eg From: [EMAIL PROTECTED]) [RFC2616]. This enables the discovered information to vary based on the RP. The From field is not authenticated so it is not appropriate to use for access control.” Other solutions: The source IP address of the discovery request will often identify the RP, but this would be an unreliable mechanism due to proxies, clusters, load balancing, and changes at the RP. Separate user-supplied identifiers could be used, but that unnecessarily complicates the system for users. OPs can offer different authentication mechanisms based on the openid.return_to or openid.realm parameter in an authentication request. However, the user has less flexibility when they have to relying on OPs. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] identify RP when it gets OpenID URL
The User-Agent field does not have the right semantics. I hope that field could be used, for instance, to notice which Relying Parties are using a particular version of Janrain’s Java library for OpenID. It is probably reasonable for Bloglines, Google etc to identify themselves in the User-Agent field as they probably use proprietary purpose-built clients. Most OpenID RPs will not use proprietary clients. The From field feels more appropriate for this OpenID purpose. From: John Panzer [mailto:[EMAIL PROTECTED] Sent: Wednesday, 17 October 2007 2:36 PM To: Manger, James H Cc: specs@openid.net Subject: Re: [OpenID] identify RP when it gets OpenID URL Wouldn't User-Agent: be equivalent, and have prior art (feed readers such as Bloglines identify themselves via User-Agent)? Manger, James H wrote: … “The Relying Party MUST include a From HTTP header field in each HTTP request made during discovery. The From field holds an email address for the RP (eg From: [EMAIL PROTECTED]) [RFC2616]. This enables the discovered information to vary based on the RP. The From field is not authenticated so it is not appropriate to use for access control.” … ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] identify RP when it gets OpenID URL
PAPE may be another approach (to support per-user per-RP login policies). It certainly will not always be “cleaner”. It is not a reason against enabling a discovery-based approach. This PAPE suggestion requires the RP and OP to implement what the user wants. A discovery-based approach only requires the web site hosting the user’s identifier to implement what the user wants. The PAPE-enabled backup service requests that the OP authenticates Alice in a manner compliant with certain policies, that are satisfactory to Alice's security requirements for a backup service. PAPE must be implemented by the backup service AND the OP. Alice’s policy must be expressible in PAPE’s language. The backup service must have a GUI for Alice to choose her security requirements. The backup service has to remember per-user login requirements – which is rather at odds with a main point of OpenID of the RP not having to be involved with how Alice is authenticated. Every other RP where Alice wants to tweak her login policy also needs to support this… Please don’t make this the only way to implement this style of feature. There have always been 4 entities in an OpenID login: the user (with a browser); the OP; the RP; and the web site hosting the user’s identifier. The last entity can simply be a static HTML page, which is a huge bonus. Identifying the RP to this entity enables (but doesn’t require) it to be more than a static page – when that is useful (ie for users, circumstances and functions where it turns out to be the easiest implementation point). _ From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Thursday, 18 October 2007 4:15 AM To: Manger, James H Cc: specs@openid.net I believe there's a cleaner way to address this, that would not complicate the things that Alice needs to know about the inner workings of OpenID (and without her having to use different identities for different purposes): The PAPE-enabled backup service requests that the OP authenticates Alice in a manner compliant with certain policies, that are satisfactory to Alice's security requirements for a backup service. From: Manger, James H Sent: Wednesday, 17 October 2007 12:59 PM To: 'specs@openid.net' Subject: [OpenID] identify RP when it gets OpenID URL … Add the following paragraph at the end of section 7.3 Discovery: “The Relying Party MUST include a From HTTP header field in each HTTP request made during discovery. The From field holds an email address for the RP (eg From: [EMAIL PROTECTED]) [RFC2616]. This enables the discovered information to vary based on the RP. The From field is not authenticated so it is not appropriate to use for access control.” … ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
[OpenID] identify RP when it gets OpenID URL
It can be useful to know who the Relying Party (RP) is during the discovery phase. That is, the RP should state their identify when they are looking up a user’s OpenID URL (Claimed Identifier). Use case: Alice wants to use different OPs for different RPs, while keeping the same URL (eg http://alice.example.net/). For instance, when logging into a service hosting her backups she wants to use an OP that requires a one-time password from a hardware token for each access. However, when leaving comments on blogs Alice wants to authenticate using an OP that only requires a password and uses a persistent cookie so she only has to log in once a day. Problem: Only one OP can be specified with a link rel=openid2.provider…/ element or in a Yadis document. [A Yadis document may be able to list many OPs, but I don’t think there is any mechanism for the RP to pick the right one.] Solution: The RP could include a From HTTP header when performing discovery. Instead of serving a static HTML page (or Yadis document) at http://alice.example.net/, the page could be dynamically generated based on the value of the From header. Suggested text for the authentication spec (draft 12): Add the following paragraph at the end of section 7.3 Discovery: “The Relying Party MUST include a From HTTP header field in each HTTP request made during discovery. The From field holds an email address for the RP (eg From: [EMAIL PROTECTED]) [RFC2616]. This enables the discovered information to vary based on the RP. The From field is not authenticated so it is not appropriate to use for access control.” Other solutions: The source IP address of the discovery request will often identify the RP, but this would be an unreliable mechanism due to proxies, clusters, load balancing, and changes at the RP. Separate user-supplied identifiers could be used, but that unnecessarily complicates the system for users. OPs can offer different authentication mechanisms based on the openid.return_to or openid.realm parameter in an authentication request. However, the user has less flexibility when they have to relying on OPs. James Manger ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: DRAFT 11 - FINAL? openid2
Supporting point 2 (user with a v1 OP and a *separate* v2 OP) seems a bit unnecessary. A single OP can support v1 and v2 RPs at the same time. Point 2 is the sort of corner-case that can be supported by a yardis file, but needn’t be supported by the simple HTML discovery alternative. My vote would be to keep openid.server and openid.delegate (instead of openid2.provider and openid2.local_id) and add openid.version. P.S. The spec should talk about link …/, instead of LINK …, elements. It does this in the §A.4 “HTML Identifier Markup” example, but not in §7.3.3 “HTML-based discovery”. Version 1.1 used link …; HTML is case-insensitive so link … is ok; XHTML is case-sensitive so LINK …/ is not acceptable. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Wednesday, 31 January 2007 12:50 PM To: Recordon, David Cc: specs@openid.net Subject: Re: DRAFT 11 - FINAL? On 1/30/07, Recordon, David [EMAIL PROTECTED] wrote: 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. 1. Before authentication is initiated, the RP needs to determine what the protocol is. This could be done via discovery on the OP, but there has been general rejection of adding yet another discovery step. 2. A user may have one service that provides OpenID 1 and another that provides OpenID 2. If this is the case, then the version information needs to be bound to the link tag that contains the information. Given (1), the information needs to be embedded in the HTML markup. Given (2), the information needs to be tied to the specific link tag. For example: link rel=openid.server href=http://op.example.com/openid1; link rel=openid2.provider href=http://op.example.com/openid2; vs. link rel=openid.server href=http://op.example.com/openid1; link rel=openid.provider href=http://op.example.com/openid2; link rel=openid.protocol_version href=http://specs.openid.net/auth/2.0; While it is true that since the link relationship names changed, the openid2 is technically redundant, I think it is much clearer to everybody what is going on if the link relationship contains the version number. If the protocol version were to keep changing, I'd argue for a different solution. 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
[OpenID] btwoc, base64 and the default DH modulus
--- The default Diffie-Hellman modulus is shown in decimal in version 1.1 and in hex in version 2.0predraft11, but would appear in base64(btwoc(…)) in the protocol! Change Appendix B Diffie-Hellman Key Exchange Default Value to use the base64(btwoc(p)) format, as used in the protocol (see §8.1.2 Diffie-Hellman Request Parameters). “Appendix B. Diffie-Hellman Key Exchange Default Value This is the prime number p used as the default modulus for Diffie-Hellman Key Exchange, in base64(bwtoc(p)) format: * openid.dh_modulus Value: ANz5OguIOXLsDhmYmsWizjEOHTdxfo2Vcbt2I3MYZuYe91ouJ4mLBX+YkcLiemOc Pym2CBRYHNOyyjmG0mg3BVd9RcLn5S3IHHoXGHblzqdLFEi/368Ygo79JRnxTkXj gmY0rxlJ5bU1zIKaSDuKdiI+XUkKJX8Fvf8W8vsixYOr ” --- The table in §4.7 Integer Representations is misleading as it unnecessarily introduces \x00 notation and quotes. Base64-encoding is always applied after btwoc so show this in the table. Adjust the last sentence to avoid confusion between bytes and strings. From: “If it is not, implementations MUST add a zero byte at the front of the string.” To: “If it is not, add a zero byte at the front.” Add an extra sentence: “The base64-encoding of the btwoc bytes is transmitted in the protocol.” Replace the table with the following: “Base 10 Number | btwoc bytes | base64(btwoc(…)) ---+-+- 0 | 00 | AA== 127| 7F | fw== 128| 00 80 | AIA= 255| 00 FF | AP8= 32768 | 00 80 00| AIAA ” ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
[OpenID] inconsistent openid. prefix
OpenID Authentication 2.0 predraft 11 uses the openid. prefix inconsistently. For instance, §5.2.3 has dot-points for “openid.mode”, “openid.error”, “openid.contact”…, whereas §5.1.2.2 has dot-points for “error”, “contact”…. The data format example (§4.1.3) uses “mode” and “error” keys in the Key-Value Form encoding, but “openid.mode” and “openid.error” in the x-www-urlencoded example in the very next paragraph. I assume it should be “openid.mode” and “openid.error” everywhere. Text such as Value: associate or Default: HMAC-SHA1 appears throughout the spec. A assume the quotes do NOT appear in the protocol. A sentence to this effect in §4.1 Protocol Messages would help, as would more comprehensive examples. Add this sentence to §4.1: “Specific values are shown in double quotes within this specification (eg Value: associate) but the quotes do not appear in the protocol messages (eg openid.mode=associate).” ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] Assertion Quality Extension = openid.importance
The RP is not saying “this is very very important to *me*”. It is saying “in my opinion, this is likely to be very very important to *you*”. Consequently, it is not a contradiction for the RP to also say “I leave it to you as to the specifics”. Does participating in OpenID mean the RP giving up this policy control? Yes, fully participating in OpenID means the RP gives up some policy control. An RP cannot simultaneously 1) accept its users choices of OPs, and 2) get trusted assertions as to the authentication quality. The first implies accepting any OP. The second implies accepting only the small subset of OPs trusted by the RP. How many such RPs will be willing to pay this price? For most RPs there shouldn’t be a high price (if any price). When the login only gives access to the user’s own resources (be they colour preferences, reputation, personal details, money…), then any inappropriately weak authentication of the user by their OP only affects that user. The user pays a price, but not the RP. This scenario covers a lot of services: Amazon (user’s book preferences, user’s payments); hotmail (user’s inbox); flickr (user’s photos)… An RP may pay an indirect price. The law may not accept that the user was in total control of the authentication mechanism so the user (not the RP) bears all responsibility. A big scenario not covered is corporate access: the RP is a company, the user is an employee. Login gives the user access to resources, but the RP still owns the resources. Some control over the resources is delegated to the user, but not all. Solutions: a) don’t use openid, b) trust your employees, c) use openid but only accept selected OPs. Fundamentally, I don't see how acknowledging that the RP may have certain expectations of the authentication event is somehow in conflict with user-centrism. The hassle is that an RP expectation for, say, “hardotp” will prevent my spec-compliant OP software from logging me in even if I am using a triple-factor iris scan, 20-char password and smartcard to authenticate myself to my OP. A related hassle is that when my OP supports a new authentication method (such as a strong password-authenticated key agreement scheme (eg SRP)), existing RPs will not recognize this method as strong enough for the RP’s expectations – regardless of the method’s actual strength. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] Assertion Quality Extension = openid.importance
What happened to all the concern about openid.auth_age (in early October)? I echo Kevin Turner's worry that “features like this will mislead the RP developers into thinking they have more control over the authentication protocol than they really do… when OpenID actually leaves all those controls in the hands of the user and their chosen IdP”. [http://openid.net/pipermail/specs/2006-October/000223.html] Dick Hardt’s Amazon.com use case makes sense: amazon.com may be quite happy to use an arbitrarily old authentication to personalise your browsing, but when you go to purchase something they want to make sure it is still you (and prompt you for your password). The user-centric solution is not for the RP to specify a max auth age (or captcha or email verification or handbio or hardotp…), but for the RP to indicate the importance of the authentication. The user (with a little help from their OP) decides how to react (eg whether or not to login again) based on the importance/RP/auth-age/…. Spec changes: specify an openid.importance attribute to be included in an authentication request and echoed in the response; define some standard values (eg “low”, “medium”, “high”, “session”, “transaction”, “money”, “privacy”, “corporate”, “reputation”…); encourage OPs to allow users to control how when to reauthenticate based on the importance and RP. Surely the Assertion Quality Extension (AQE) will just encourage RP to only support a small number of OPs that the RP can trust to enforce the RP’s rules. James Manger ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
