Re: OpenID Trusted Authentication Extension
On 8/31/07, James Henstridge [EMAIL PROTECTED] wrote: You still want the user involved in the granting of an authentication token though, right? Trying to replace the UA in the authentication workflow is quite a big change, and limits what the OP can do. Yes, granting the secret must be done using the traditional User Agent, as the user must be logged in using their normal credentials in order for the OP to deliver the secret to the requesting RP. Considering it's an Extension, this isn't really any sort of change that limits what the OP can do. It simply codes a standard credential format that is only used for when a site wishes to log into another site using a specific OpenID. With your proposal, the user's OP needs to implement an extension. This brings up a few questions: 1. Should the data provider only let users register if their OP implements the extension? What is the benefit to the data provider in enforcing such an extension? Trusted Authentication doesn't require the destination site (the DP) to implement any changes at all. One would hope that the DP is offering some valuable service other than just providing data to client sites. As for the client site, yes, functionality will be lost if the OP doesn't support the extension that would allow them to log in to another site. If the extension becomes popular, it would be in the best interest of the OP to implement the extension if they wanted to keep users from switching to a different provider that does support the extension. 2. If only some users' OPs implement the extension, can the data consumer rely on the protocol at all? Why not? They would be able to support this, and if the OP doesn't support the extension, they can continue using those very insecure API key implementations that are being used today. Or, they can even suggest that the user switch to a supporting provider. In contrast, both the data provider and consumer have an incentive to implement an extension for auth token transfer, so a spec that only requires modifications to those parties seems easier to roll out. What do you think? Well, as above, no changes are needed at the DP. I think it would be much easier to simply modify the hand-full of OPs and the Client RPs that want to support the spec, which is expected with any OpenID extension. [snip] to log on to the destination site to invalidate the token. What if the user has 50 of these API connections set up? That's 50 sites to visit in order to manage these tokens. I guess that is a concern. But how often do you expect the data provider to check the user's OP to see if the token is still valid? If it doesn't check often, then revoking the token at the OP level might take a while to take effect. Well, it really is up to the DP to determine how long it wants its sessions open, just with any other website. For instance, banks will automatically expire the session if there is no activity for 15 minutes. In this case, the DP will simply force the Client RP to authenticate again with the OP. As stated in the spec, it's not my intention to mandate how user data (and the data session) is managed between the client RP and the DP. Your feedback is always welcome. Thanks, John ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Trusted Authentication Extension
Well, I've slept on it. I think we have a difference in philosophy. The other Extesions - AX, Simple Registration, etc. - follow the same data flow methodology: RP - UA - OP RP - UA - OP I believe I'm sticking to the same principles in my spec. We are doing the very same thing when we collect the authentication key (see above). We are even doing the very same thing when we have the sites authenticate with each other. It's just we have a non-human operating the User Agent. In this case, the RP is the destination site, the UA is the client site: RP - UA - OP RP - UA - OP I think this fits well with what people expect. I also have no problem with having OPs incrementally improve their systems to make them compatible with new extensions. Since there will (eventually) be far more RPs out there than OPs, I think it's reasonable for them to support the bulk of the extension implementation. In this case, however, there really isn't all that much to implement. The following code changes will need to happen at the site that wants access to information at another site (the CC): * The form where the user submits their OpenID to grant permission to another site * Logic that builds a simple OpenID login request with the Trusted Authentication data included, and a redirect to the OP * A branch to the id_res checker that parses the OP response and stores the shared secret * An automated script that performs OpenID authentication to the DC and retreives data The OP needs to implement the following: * When receiving a check_id request with Trusted Authentication arguments, send an X-OPENID-TrustedAuthentication HTTP header in the response, and be able to accept a SHA-256 hash as a response - This is not a big deal, and isn't any form of deviation, because this is the gray area in the spec where the UA is supposed to be verified that it's already logged in, or is prompted for credentials * Add a logic branch that generates a shared secret when requested, stores it, and sends it in the authentication response * Some form of user interface to manage the stored secrets - very easy All but one of these steps would be needed to implement ANY OpenID extension out there. And the only change that is out of spec is accepting an SHA-256 hash as an authentication key - which is trivial to implement at an OP. Conservatively, (with distractions) I think an OP can implement the data passing in less than a couple of hours, and the user interface in a couple of days. Although your implementation is sound, and I like a lot of the ideas, they shift a lot of the responsibility to the party receiving the authentication request. I'm not sure I like the idea of having the burden of implementing both an API and a special pseudo-OP. This also removes the power of having a single Identity management interface at the OP, meaning the user will have to log on to the destination site to invalidate the token. What if the user has 50 of these API connections set up? That's 50 sites to visit in order to manage these tokens. Like I said, nothing technically wrong with the idea (it's novel), but it just doesn't fit with me. Thank you! John Ehn 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/. 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/. 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
Re: OpenID Trusted Authentication Extension
On 31/08/2007, John Ehn [EMAIL PROTECTED] wrote: Well, I've slept on it. I think we have a difference in philosophy. The other Extesions - AX, Simple Registration, etc. - follow the same data flow methodology: RP - UA - OP RP - UA - OP With my proposed workflow, it'd be going through the UA too. The checkid_setup request and id_res response uses indirect communication, so those calls do go through the user agent. I did not specify this explicitly in my previous email because it is implied. So the workflow would look something like this if the data provider needs to authenticate the user: DC - UA - DP - UA - OP DC - UA - DP - UA - OP In the communication between DC and DP, the DC is the RP and the DP is the OP. In communication between the DP and OP, the DP is the RP and the OP is the OP. I believe I'm sticking to the same principles in my spec. We are doing the very same thing when we collect the authentication key (see above). We are even doing the very same thing when we have the sites authenticate with each other. It's just we have a non-human operating the User Agent. In this case, the RP is the destination site, the UA is the client site: RP - UA - OP RP - UA - OP You still want the user involved in the granting of an authentication token though, right? Trying to replace the UA in the authentication workflow is quite a big change, and limits what the OP can do. I think this fits well with what people expect. I also have no problem with having OPs incrementally improve their systems to make them compatible with new extensions. Since there will (eventually) be far more RPs out there than OPs, I think it's reasonable for them to support the bulk of the extension implementation. With your proposal, the user's OP needs to implement an extension. This brings up a few questions: 1. Should the data provider only let users register if their OP implements the extension? What is the benefit to the data provider in enforcing such an extension? 2. If only some users' OPs implement the extension, can the data consumer rely on the protocol at all? In contrast, both the data provider and consumer have an incentive to implement an extension for auth token transfer, so a spec that only requires modifications to those parties seems easier to roll out. What do you think? [snip] Although your implementation is sound, and I like a lot of the ideas, they shift a lot of the responsibility to the party receiving the authentication request. I'm not sure I like the idea of having the burden of implementing both an API and a special pseudo-OP. This also removes the power of having a single Identity management interface at the OP, meaning the user will have to log on to the destination site to invalidate the token. What if the user has 50 of these API connections set up? That's 50 sites to visit in order to manage these tokens. I guess that is a concern. But how often do you expect the data provider to check the user's OP to see if the token is still valid? If it doesn't check often, then revoking the token at the OP level might take a while to take effect. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
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
Re: OpenID Trusted Authentication Extension
Chris, I want to start off by saying how horribly inappropriate it is to use the OpenID specifications mailing list to peddle an authentication standard that has absolutely nothing to do with OpenID. I find it interesting that so many of the OAuth community have taken time out of their busy schedules to tell me to back off on my extension to OpenID. Every single response to my specification has mentioned OAuth, and all with a very defensive tone. Only one or two responses have had any constructive criticism about the actual content of the specification. To MY defense, I didn't even know about OAuth until I was reminded of it in response to my specification. I have attempted to review the spec, but am unable to locate it anywhere, even though I joined the Google Group, as requested. Due to the very public negative response from the OAuth folks, I am tempted to remove myself from the group as a result. As for consensus, I simply don't care. This was an exercise to allow OpenID to fill the needs of a specific use case. I believe it is extremely simple to implement, and is reasonably secure. If the OpenID folks decide to adopt it, I will be very happy. If not, I will still be happy. I am passionate about OpenID. I feel that if I want it succeed, I should work to extend it, and I should have the freedom to do so. Thank you, John Ehn On 8/29/07, Chris Messina [EMAIL PROTECTED] wrote: Hi John, Looks like there's some consensus around OAuth... ;) I helped to get OAuth off the ground to solve the very problem that you're looking to solve -- in our case, enabling Ma.gnolia OpenID users to use Dashboard Widgets and Twitter API users to authenticate their apps, eventually using OpenID. While I appreciate your work on an OpenID-specific extension, I think there's some legitimacy in looking at a solution that works generally regardless of the authentication mechanism. By decoupling OpenID and OAuth, the goal was to make it easier to adopt OAuth first and then lead into adopting OpenID. In the case of your spec, which seems like a good piece of work, there'd be no sense in supporting the extension without supporting OpenID and as such, has limited benefit in the wild for implementors. With OAuth, if we're able to get folks like AOL, Google, Yahoo and others to support it, the amount of effort necessary to support all of them becomes the same amount of work to support one. Anyway, I'm glad to see you on the OAuth list. Feel free to poke around; we're looking to put out a 0.9 Draft and have it implemented over the course of September in libraries and then release finally a 1.0 Oct 1. Cheers, Chris On 8/27/07, David Fuelling [EMAIL PROTECTED] wrote: John, Have a look at OAuth (http://groups.google.com/group/oauth). I think it's currently a private google group, but it seems like you've given a lot of thought to this type of thing, so I'm sure the group owners would welcome your input. There's a lot of activity going on over there. David On 8/26/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 Thank you, John Ehn [EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Chris Messina Citizen Provocateur Open Source Advocate-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Trusted Authentication Extension
Hi John, Looks like there's some consensus around OAuth... ;) I helped to get OAuth off the ground to solve the very problem that you're looking to solve -- in our case, enabling Ma.gnolia OpenID users to use Dashboard Widgets and Twitter API users to authenticate their apps, eventually using OpenID. While I appreciate your work on an OpenID-specific extension, I think there's some legitimacy in looking at a solution that works generally regardless of the authentication mechanism. By decoupling OpenID and OAuth, the goal was to make it easier to adopt OAuth first and then lead into adopting OpenID. In the case of your spec, which seems like a good piece of work, there'd be no sense in supporting the extension without supporting OpenID and as such, has limited benefit in the wild for implementors. With OAuth, if we're able to get folks like AOL, Google, Yahoo and others to support it, the amount of effort necessary to support all of them becomes the same amount of work to support one. Anyway, I'm glad to see you on the OAuth list. Feel free to poke around; we're looking to put out a 0.9 Draft and have it implemented over the course of September in libraries and then release finally a 1.0 Oct 1. Cheers, Chris On 8/27/07, David Fuelling [EMAIL PROTECTED] wrote: John, Have a look at OAuth (http://groups.google.com/group/oauth). I think it's currently a private google group, but it seems like you've given a lot of thought to this type of thing, so I'm sure the group owners would welcome your input. There's a lot of activity going on over there. David On 8/26/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 Thank you, John Ehn [EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Chris Messina Citizen Provocateur Open Source Advocate-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Trusted Authentication Extension
John, Have a look at OAuth (http://groups.google.com/group/oauth). I think it's currently a private google group, but it seems like you've given a lot of thought to this type of thing, so I'm sure the group owners would welcome your input. There's a lot of activity going on over there. David On 8/26/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 Thank you, John Ehn [EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID Trusted Authentication Extension
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 Thank you, John Ehn [EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
