Re: OpenID Trusted Authentication Extension

2007-08-30 Thread James Henstridge
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

2007-08-30 Thread John Ehn
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

2007-08-30 Thread James Henstridge
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

2007-08-30 Thread John Ehn
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