Re: OpenID Trusted Authentication Extension
On 26/08/07, John Ehn [EMAIL PROTECTED] wrote: I have created a draft of a new specification that I think will help to fill a gap in OpenID functionality. What appears to be a newer productivity feature of many websites is the ability to import and utilize information from other sites. For instance, Basecamp provides an API that allows other systems to access user data. This is a great feature, but it currently cannot be done with OpenID, due to the dependence on end-user interaction during the authentication process. The Trusted Authentication Extension provides for the ability for an OpenID Consumer to log in to another OpenID Consumer without user interaction. The end user will be able to create a trusted connection between two OpenID enabled sites, which will allow a client site to access a destination site using the end user's Identity. Please provide your comments and feedback, as they are most appreciated. http://extremeswank.com/openid_trusted_auth.html I think things would be a bit clearer if you made the data provider into a form of OpenID Provider. I think it helps to first consider the case where the data provider is not an OpenID Relying party but instead has its own user account database. If the site acted as an OpenID provider, it would be pretty simple to use an extension to negotiate an auth token to acess data for the user. Simply start an OpenID authentication request, including some field stating that you want access to data. The provider would then include an authentication token in the response that could be used to access the web services. Now lets consider the case where the data provider identifies users by an OpenID. What would happen if the data provider continued to implement an OP, and the data consumer started an OpenID authentication request with it using the user's data provider. This would let us use the same sort of OpenID extension to negotiate the auth token. The data provider could even turn around and perform its own authentication request to verify that the user is who they say they are, since it received the identity URL from the data consumer. So the full workflow might go like this: DC: Data Consumer DP: Data Provider OP: User's OpenID Provider 1. DC sends checkid_setup request to DP for user's identity URL, with an extension asking to negotiate an auth token. 2. DP initiates OpenID authentication for user's identity URL 3. OP verifies user's identity and sends idres reply to DP. 4. DP sends idres reply to DC, including the auth token as an extension in the response. This seems to give similar results to your protocol while introducing fewer new concepts. What do you think? James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Trusted Authentication Extension
James, Sorry, but I'm having problems following the flow. It seems like an interesting idea, though. Can you provide with a little more information on how these components would interact? I was really trying to keep everything dumb and simple. The concept I was going for was piggy-back on OpenID, but include a way to programmatically log on to the OpenID Provider. The problem I saw with OpenID was that there are about a million different ways to authenticate with an OpenID Provider, from HTML forms to digital certificates. Most require the User Agent to be a web browser. However, there is no standard way to just pass a credential that can prove that you are who you say you are. Trusted Connection Request: User Agent gives OpenID to Client Consumer Client Consumer - User Agent - OpenID Provider Trusted Connection Response (with key): Client Consumer - User Agent - OpenID Provider Trusted Logon: Client Consumer gives OpenID Identity to Destination Consumer Destination Consumer - Client Consumer - OpenID Provider Destination Consumer - Client Consumer - OpenID Provider I was trying to solve the problem by coming up with an automatable (if that's a word) way to authenticate with an OpenID Provider. If we have that, there's no need to pass around a special token, because we can just use standard OpenID authentication if we want to log on to another system. So, I proposed just having the Consumer get a key from the OpenID Provider that it can use to automatically authenticate with the Provider in the future. The key is passed through the user when it's granted, because you need the user to approve the whole thing anyway. I don't expect this extension to fix all problems. It's only intended to solve a specific use case (website to website info sharing). I am working on two additional extensions which will solve the other problems I see: * Inline Authentication - Provide support for legacy and real-time interactive systems that can't launch a web browser, and are protecting their own data (Telnet, etc). This will involve manually-typed verification keys. * Desktop Authentication - Provide for desktop applications authenticating with and accessing data behind third-party systems (RSS readers, chat, etc). I appreciate any feedback you can give me. Thank you! John Ehn On 8/30/07, James Henstridge [EMAIL PROTECTED] wrote: On 26/08/07, John Ehn [EMAIL PROTECTED] wrote: I have created a draft of a new specification that I think will help to fill a gap in OpenID functionality. What appears to be a newer productivity feature of many websites is the ability to import and utilize information from other sites. For instance, Basecamp provides an API that allows other systems to access user data. This is a great feature, but it currently cannot be done with OpenID, due to the dependence on end-user interaction during the authentication process. The Trusted Authentication Extension provides for the ability for an OpenID Consumer to log in to another OpenID Consumer without user interaction. The end user will be able to create a trusted connection between two OpenID enabled sites, which will allow a client site to access a destination site using the end user's Identity. Please provide your comments and feedback, as they are most appreciated. http://extremeswank.com/openid_trusted_auth.html I think things would be a bit clearer if you made the data provider into a form of OpenID Provider. I think it helps to first consider the case where the data provider is not an OpenID Relying party but instead has its own user account database. If the site acted as an OpenID provider, it would be pretty simple to use an extension to negotiate an auth token to acess data for the user. Simply start an OpenID authentication request, including some field stating that you want access to data. The provider would then include an authentication token in the response that could be used to access the web services. Now lets consider the case where the data provider identifies users by an OpenID. What would happen if the data provider continued to implement an OP, and the data consumer started an OpenID authentication request with it using the user's data provider. This would let us use the same sort of OpenID extension to negotiate the auth token. The data provider could even turn around and perform its own authentication request to verify that the user is who they say they are, since it received the identity URL from the data consumer. So the full workflow might go like this: DC: Data Consumer DP: Data Provider OP: User's OpenID Provider 1. DC sends checkid_setup request to DP for user's identity URL, with an extension asking to negotiate an auth token. 2. DP initiates OpenID authentication for user's identity URL 3. OP verifies user's identity and sends idres reply to DP. 4. DP sends idres reply to DC, including the auth token as an
Re: OpenID Trusted Authentication Extension
On 30/08/2007, John Ehn [EMAIL PROTECTED] wrote: James, Sorry, but I'm having problems following the flow. It seems like an interesting idea, though. Can you provide with a little more information on how these components would interact? Okay. The basic idea was that instead of creating a special protocol for two OpenID relying parties to communicate with each other was for the web services data provider to act as an OpenID provider. So, lets assume that the data consumer wants an auth token for the user identified by http://user.identifier.url. With normal OpenID authentication, you'd perform discovery to find the user's OpenID provider. To request an auth token though we need to talk to the data provider, so instead we skip discovery and perform an authentication request to the data provider's endpoint. The parameters might look something like this: * openid.mode = checkid_setup * openid.claimed_id = http://user.identifier.url * openid.identity = http://user.identifier.url * openid.return_to = http://data.consumer/... * openid.ns.auth = ... * (additional parameters related to the auth token request) The data provider would then decide whether to grant the auth token (possibly by performing OpenID authentication against http://user.identifier.url, and/or asking the user), then send a response back like: * openid.mode = id_res * openid.claimed_id = http://user.identifier.url * openid.identity = http://user.identifier.url * openid.return_to = http://data.consumer/... * openid.ns.auth = ... * openid.auth.token = ... * openid.auth.secret = ... The data consumer knows that the request came from the data provider due to the signature on the OpenID response. The data provider knows which user to create the token for because it was present in the OpenID request. The data provider can verify that the web browser user is that user because control gets transferred to the data provider during the authentication process. This all assumes that the data consumer has already authenticated the user, so knows which identity URL to request a token for from the data provider. I was really trying to keep everything dumb and simple. The concept I was going for was piggy-back on OpenID, but include a way to programmatically log on to the OpenID Provider. The problem I saw with OpenID was that there are about a million different ways to authenticate with an OpenID Provider, from HTML forms to digital certificates. Most require the User Agent to be a web browser. However, there is no standard way to just pass a credential that can prove that you are who you say you are. Well, OpenID authentication requests are designed to let the OP perform whatever checking they want before sending a response. So by making the data provider act as an OP, it has the same freedom (including the freedom to issue its own OpenID authentication request to the user's actual OP). I was trying to solve the problem by coming up with an automatable (if that's a word) way to authenticate with an OpenID Provider. If we have that, there's no need to pass around a special token, because we can just use standard OpenID authentication if we want to log on to another system. So, I proposed just having the Consumer get a key from the OpenID Provider that it can use to automatically authenticate with the Provider in the future. The key is passed through the user when it's granted, because you need the user to approve the whole thing anyway. I think that this makes things more complicated than need be. If you want an auth token from the data provider it seems better to ask the data provider for the key directly, giving it the chance to authenticate the user before responding. This also has the benefit that it does not require any special features from the user's OP -- the extension is purely concerned with the interaction between data consumer and provider. I don't expect this extension to fix all problems. It's only intended to solve a specific use case (website to website info sharing). I am working on two additional extensions which will solve the other problems I see: Sure. I doubt my suggested workflow would help with those use cases either (at least without some additional components). James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Trusted Authentication Extension
Ahhh, I see what you're going for. It's a very interesting idea. On 8/30/07, James Henstridge [EMAIL PROTECTED] wrote: On 30/08/2007, John Ehn [EMAIL PROTECTED] wrote: James, Sorry, but I'm having problems following the flow. It seems like an interesting idea, though. Can you provide with a little more information on how these components would interact? Okay. The basic idea was that instead of creating a special protocol for two OpenID relying parties to communicate with each other was for the web services data provider to act as an OpenID provider. So, lets assume that the data consumer wants an auth token for the user identified by http://user.identifier.url. With normal OpenID authentication, you'd perform discovery to find the user's OpenID provider. To request an auth token though we need to talk to the data provider, so instead we skip discovery and perform an authentication request to the data provider's endpoint. The parameters might look something like this: * openid.mode = checkid_setup * openid.claimed_id = http://user.identifier.url * openid.identity = http://user.identifier.url * openid.return_to = http://data.consumer/... * openid.ns.auth = ... * (additional parameters related to the auth token request) The data provider would then decide whether to grant the auth token (possibly by performing OpenID authentication against http://user.identifier.url, and/or asking the user), then send a response back like: * openid.mode = id_res * openid.claimed_id = http://user.identifier.url * openid.identity = http://user.identifier.url * openid.return_to = http://data.consumer/... * openid.ns.auth = ... * openid.auth.token = ... * openid.auth.secret = ... The data consumer knows that the request came from the data provider due to the signature on the OpenID response. The data provider knows which user to create the token for because it was present in the OpenID request. The data provider can verify that the web browser user is that user because control gets transferred to the data provider during the authentication process. This all assumes that the data consumer has already authenticated the user, so knows which identity URL to request a token for from the data provider. I was really trying to keep everything dumb and simple. The concept I was going for was piggy-back on OpenID, but include a way to programmatically log on to the OpenID Provider. The problem I saw with OpenID was that there are about a million different ways to authenticate with an OpenID Provider, from HTML forms to digital certificates. Most require the User Agent to be a web browser. However, there is no standard way to just pass a credential that can prove that you are who you say you are. Well, OpenID authentication requests are designed to let the OP perform whatever checking they want before sending a response. So by making the data provider act as an OP, it has the same freedom (including the freedom to issue its own OpenID authentication request to the user's actual OP). I was trying to solve the problem by coming up with an automatable (if that's a word) way to authenticate with an OpenID Provider. If we have that, there's no need to pass around a special token, because we can just use standard OpenID authentication if we want to log on to another system. So, I proposed just having the Consumer get a key from the OpenID Provider that it can use to automatically authenticate with the Provider in the future. The key is passed through the user when it's granted, because you need the user to approve the whole thing anyway. I think that this makes things more complicated than need be. If you want an auth token from the data provider it seems better to ask the data provider for the key directly, giving it the chance to authenticate the user before responding. This also has the benefit that it does not require any special features from the user's OP -- the extension is purely concerned with the interaction between data consumer and provider. I don't expect this extension to fix all problems. It's only intended to solve a specific use case (website to website info sharing). I am working on two additional extensions which will solve the other problems I see: Sure. I doubt my suggested workflow would help with those use cases either (at least without some additional components). James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs