Re: OpenID Trusted Authentication Extension

[John Ehn]

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

[James Henstridge]

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

[John Ehn]

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/. ..
> * 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 t

Re: OpenID Trusted Authentication Extension

[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

Re: OpenID Trusted Authentication Extension

[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

[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 s

Re: OpenID Trusted Authentication Extension

[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

[John Ehn]

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

[Chris Messina]

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

[David Fuelling]

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