[oauth] Re: Authentication API protected with OAuth

[Praveen Alavilli]

Most of the major providers that I know use SSL behind netscalars too
for their login servers. Usually netscalers persist the connections
with the origin servers so there is still huge performance improvement
while securing the data in transit in the internal network.
Of course passwords still have to be sent over post not just to get
them off of server logs but to prevent the browsers from storing it in
users history.

-Praveen

On 1/30/09, George Fletcher  wrote:
>
> Agreed. I don't think this solution works for everyone.
>
> Though from that post it seems that unless the site is using SRP the
> password is going in clear-text over the wire (SSL) for sites that store
> salted hashes. (I just used Live HTTP headers to verify a major online
> service provider and this is the case. The password is in clear-text
> over SSL) If the site uses something like a netscaler to offload their
> SSL, then the clear-text password is in the clear inside the company's
> network. Hopefully, most sites using this scheme make sure the password
> is specified in a POST to ensure it's not being stored in clear-text in
> the server's log files:)
>
> Thanks,
> George
>
> Brian Eaton wrote:
>> On Wed, Jan 28, 2009 at 6:41 PM, George Fletcher  wrote:
>>
>>> The request is only valid if the receiving
>>> authentication system can generate the signature using the password for
>>> that user.
>>>
>>
>> Lots of authentication servers can't do that, because they do not keep
>> a clear-text version of the user's password.  Instead they store a
>> salted hash.
>>
>> I love Thomas Ptacek's summary of password storage schemes:
>> http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/
>>
>> >
>>
>>
>
> --
> Chief Architect   AIM:  gffletch
> Identity Services Work: george.fletc...@corp.aol.com
> AOL LLC   Home: gffle...@aol.com
> Mobile: +1-703-462-3494
> Office: +1-703-265-2544   Blog: http://practicalid.blogspot.com
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Authentication API protected with OAuth

[George Fletcher]

Agreed. I don't think this solution works for everyone.

Though from that post it seems that unless the site is using SRP the 
password is going in clear-text over the wire (SSL) for sites that store 
salted hashes. (I just used Live HTTP headers to verify a major online 
service provider and this is the case. The password is in clear-text 
over SSL) If the site uses something like a netscaler to offload their 
SSL, then the clear-text password is in the clear inside the company's 
network. Hopefully, most sites using this scheme make sure the password 
is specified in a POST to ensure it's not being stored in clear-text in 
the server's log files:)

Thanks,
George

Brian Eaton wrote:
> On Wed, Jan 28, 2009 at 6:41 PM, George Fletcher  wrote:
>   
>> The request is only valid if the receiving
>> authentication system can generate the signature using the password for
>> that user.
>> 
>
> Lots of authentication servers can't do that, because they do not keep
> a clear-text version of the user's password.  Instead they store a
> salted hash.
>
> I love Thomas Ptacek's summary of password storage schemes:
> http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/
>
> >
>
>   

-- 
Chief Architect   AIM:  gffletch
Identity Services Work: george.fletc...@corp.aol.com
AOL LLC   Home: gffle...@aol.com
Mobile: +1-703-462-3494   
Office: +1-703-265-2544   Blog: http://practicalid.blogspot.com


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Authentication API protected with OAuth

[Praveen Alavilli]

On Wed, Jan 28, 2009 at 11:05 AM, George Fletcher  wrote:


>
> In prinicple, OAuth is trying to keep the user from giving their
> credentials to any service other than their identity provider. However,
> in the case of a "client" wanting to authenticate the user to the user's
> identity provider (potentially where no browser exists), this seems like
> a much better mechanism than passing the credentials on the wire.
>
> better than using SSL transport ? It's not protecting from the user's
credentials getting exposed to the client - so if it's really to prevent
MITM/eavesdropping problems then the client is better off enforcing strict
IDP's SSL cert checks. If the assumption is that these requests are sent
over non-ssl - then yes it might add value in doing this.

More over as Brian pointed out - lot of providers cannot support this
because they don't have the user's raw password.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Authentication API protected with OAuth

[Brian Eaton]

On Wed, Jan 28, 2009 at 12:58 PM, Hans Granqvist  wrote:
> Sometimes I feel like we (people who have interest in the two concepts)
> maintain there is a difference to justify standards' existence, even if
> it's largely an academic difference with no pragmatic real meaning.

There are good reasons not to use the OAuth authorization protocol as
an authentication protocol.  (Note I said "protocol".  HMAC-SHA1 is
perfectly fine to authenticate a message, but a good authentication
protocol needs to think about what those messages say.)

Web authentication schemes should all have the following properties
(borrowing liberally from Kim Cameron's laws of identity):
- the message from the authentication authority should be signed.
This keeps someone from spoofing authentication messages.

- the message from the authentication authority should be directed: it
needs to be targeted at a specific entity.  This keeps one relying
party from replaying an authentication message to another relying
party.

- the message from the authentication authority should be timestamped:
this is necessary to prevent replay of authentication messages.

- the identity from the authentication authority should be scoped:
this is necessary to prevent one authentication authority from
authenticating users that are actually from another authentication
authority.

The OAuth protocol doesn't try to address any of those requirements,
nor should it.  It's a good delegation protocol, but that doesn't mean
it is usable out-of-the-box for authentication as well.

You can build federated authentication systems on top of the OAuth
signature scheme, though.  For one example, check out two-legged OAuth
from an opensocial container to a third-party.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Authentication API protected with OAuth

[Brian Eaton]

On Wed, Jan 28, 2009 at 6:41 PM, George Fletcher  wrote:
> The request is only valid if the receiving
> authentication system can generate the signature using the password for
> that user.

Lots of authentication servers can't do that, because they do not keep
a clear-text version of the user's password.  Instead they store a
salted hash.

I love Thomas Ptacek's summary of password storage schemes:
http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Authentication API protected with OAuth

[chris . messina]

The PIN could actually be delivered out of band at the time of
authorization (via SMS, for example).

I agree that more shared secrets doesn't necessarily help things, but
it's like FriendFeed's Remote Key... I'm not a huge fan of it since it
puts the burden on the user to remember yet another SS, but insomuch
as a PIN could enable a smoother desktop experience, as you've
described, it might be worth prototyping at least.

Chris

On 1/29/09, George Fletcher  wrote:
>
> Yes, using a PIN instead of a password would work as well. The general
> principle is that the user is using a "remembered shared secret" to sign
> the request to prove they "know" it. The OAuth signature mechanism
> provides a convenient way to do the "proof".
>
> One interesting question about your PIN idea is whether a PIN should be
> associated with a Consumer via some other, out-of-band provisioning
> process (i.e. the PIN is specific to the Consumer token). Or whether a
> PIN should be associated with a set of generic authorization
> capabilities. This is more useful if a user has only a few identities
> and a central way to manage authorization. In the current model of each
> SP also being the IdP for it's service, using a PIN model just increases
> the number of "shared secrets" the user has to remember. However, it
> does provide a way to authorize limited capabilities that passwords don't.
>
> As for software asking for passwords, I believe this has a relatively
> narrow scope. For instance the AOL desktop client asking for the AOL
> password. I agree that we should move away from the current model where
> Facebook asks for the AOL password when finding friends.
>
> Thanks,
> George
>
> Chris Messina wrote:
>> Ah ha. I get it.
>>
>> That makes sense -- though it does seem like the goal should be to
>> move away from asking for usernames and passwords.
>>
>> This, however, speaks to my concept of an account pin, where you could
>> authorize desktop apps with an easy-to-remember pin that doesn't give
>> you full account access, but only allows you to validate that you own
>> the account. So you would have a full access password (seldom used)
>> and an identification PIN -- almost like a security question (we know
>> how well those work).
>>
>> So instead of a user inputting their username and password, they would
>> input their username and PIN, and the PIN would be used to sign the
>> request, proving to the SP that it's the right user -- and then the SP
>> would provide the access token.
>>
>> Is that a similar but equally effective approach?
>>
>> Chris
>>
>> On Wed, Jan 28, 2009 at 6:41 PM, George Fletcher > > wrote:
>>
>>
>> Thanks for this history Chris. I remember it still being "API
>> authentication" in the first drafts of the OAuth IPR document; because
>> it was one of my comments on the doc:)
>>
>> 
>>
>> Here is an example usage. Again, this is more about leveraging the
>> OAuth
>> signature mechanism than trying to represent the whole OAuth flow.
>>
>> Currently at AOL we have a clientLogin API that allows a "client"
>> (think
>> destop app or mobile device) to authenticate a user and then access
>> services at AOL. Basically, the authentication credentials are
>> exchanged
>> for a token that is used subsequently to access the APIs. The user's
>> credentials are only passed to the AOL authentication service,
>> over SSL,
>> for validation.
>>
>> With the method suggested, the same validation could take place
>> but the
>> password would not be present in the request. Instead it would be used
>> to sign the request. The request is only valid if the receiving
>> authentication system can generate the signature using the
>> password for
>> that user.  The successful response of such a request would be the API
>> access token currently used.
>>
>> Another possibility (the example from the initial discussion) is using
>> this mechanism with TLS in order to return to the "client" a SAML
>> Holder-of-Key Assertion. This is the same concept of exchanging
>> one set
>> of credentials for another credential (in this case a SAML Assertion).
>>
>> I realize that there are security issues with allowing a "client"
>> or API
>> based authentication mechanism, but there are certain cases where it
>> provides a better user experience and the user is comfortable trusting
>> the application/device.
>>
>> Thanks,
>> George
>>
>> Chris Messina wrote:
>> > Hmm. Historically the separation came from the way the communities
>> > grew up actually. There were thoughts initially to make OAuth and
>> > extension of OpenID but because I was wary of the politics
>> within the
>> > OpenID community, I pushed for keeping OAuth completely separate and
>> > avoid having to do anything with authentication (so that it could be
>> > used with OpenID, bu

[oauth] Re: Authentication API protected with OAuth

[George Fletcher]

Yes, using a PIN instead of a password would work as well. The general 
principle is that the user is using a "remembered shared secret" to sign 
the request to prove they "know" it. The OAuth signature mechanism 
provides a convenient way to do the "proof".

One interesting question about your PIN idea is whether a PIN should be 
associated with a Consumer via some other, out-of-band provisioning 
process (i.e. the PIN is specific to the Consumer token). Or whether a 
PIN should be associated with a set of generic authorization 
capabilities. This is more useful if a user has only a few identities 
and a central way to manage authorization. In the current model of each 
SP also being the IdP for it's service, using a PIN model just increases 
the number of "shared secrets" the user has to remember. However, it 
does provide a way to authorize limited capabilities that passwords don't.

As for software asking for passwords, I believe this has a relatively 
narrow scope. For instance the AOL desktop client asking for the AOL 
password. I agree that we should move away from the current model where 
Facebook asks for the AOL password when finding friends.

Thanks,
George

Chris Messina wrote:
> Ah ha. I get it.
>
> That makes sense -- though it does seem like the goal should be to 
> move away from asking for usernames and passwords.
>
> This, however, speaks to my concept of an account pin, where you could 
> authorize desktop apps with an easy-to-remember pin that doesn't give 
> you full account access, but only allows you to validate that you own 
> the account. So you would have a full access password (seldom used) 
> and an identification PIN -- almost like a security question (we know 
> how well those work).
>
> So instead of a user inputting their username and password, they would 
> input their username and PIN, and the PIN would be used to sign the 
> request, proving to the SP that it's the right user -- and then the SP 
> would provide the access token.
>
> Is that a similar but equally effective approach?
>
> Chris
>
> On Wed, Jan 28, 2009 at 6:41 PM, George Fletcher  > wrote:
>
>
> Thanks for this history Chris. I remember it still being "API
> authentication" in the first drafts of the OAuth IPR document; because
> it was one of my comments on the doc:)
>
> 
>
> Here is an example usage. Again, this is more about leveraging the
> OAuth
> signature mechanism than trying to represent the whole OAuth flow.
>
> Currently at AOL we have a clientLogin API that allows a "client"
> (think
> destop app or mobile device) to authenticate a user and then access
> services at AOL. Basically, the authentication credentials are
> exchanged
> for a token that is used subsequently to access the APIs. The user's
> credentials are only passed to the AOL authentication service,
> over SSL,
> for validation.
>
> With the method suggested, the same validation could take place
> but the
> password would not be present in the request. Instead it would be used
> to sign the request. The request is only valid if the receiving
> authentication system can generate the signature using the
> password for
> that user.  The successful response of such a request would be the API
> access token currently used.
>
> Another possibility (the example from the initial discussion) is using
> this mechanism with TLS in order to return to the "client" a SAML
> Holder-of-Key Assertion. This is the same concept of exchanging
> one set
> of credentials for another credential (in this case a SAML Assertion).
>
> I realize that there are security issues with allowing a "client"
> or API
> based authentication mechanism, but there are certain cases where it
> provides a better user experience and the user is comfortable trusting
> the application/device.
>
> Thanks,
> George
>
> Chris Messina wrote:
> > Hmm. Historically the separation came from the way the communities
> > grew up actually. There were thoughts initially to make OAuth and
> > extension of OpenID but because I was wary of the politics
> within the
> > OpenID community, I pushed for keeping OAuth completely separate and
> > avoid having to do anything with authentication (so that it could be
> > used with OpenID, but would have its own adoption curve).
> >
> > The typo on the homepage was probably my fault, since, being the
> > identity n00b, I didn't realize the difference until after I
> went home
> > from the DevHouse where I put up the homepage after a couple
> beers. It
> > didn't change because (apparently!) no one else seemed to read
> it that
> > closely.
> >
> > Funny how these things develop -- not always out of explicit
> > intention, but just because of the time allotted to get the
> thing out
> > the door!

[oauth] Re: Authentication API protected with OAuth

[Chris Messina]

Ah ha. I get it.
That makes sense -- though it does seem like the goal should be to move away
from asking for usernames and passwords.

This, however, speaks to my concept of an account pin, where you could
authorize desktop apps with an easy-to-remember pin that doesn't give you
full account access, but only allows you to validate that you own the
account. So you would have a full access password (seldom used) and an
identification PIN -- almost like a security question (we know how well
those work).

So instead of a user inputting their username and password, they would input
their username and PIN, and the PIN would be used to sign the request,
proving to the SP that it's the right user -- and then the SP would provide
the access token.

Is that a similar but equally effective approach?

Chris

On Wed, Jan 28, 2009 at 6:41 PM, George Fletcher  wrote:

>
> Thanks for this history Chris. I remember it still being "API
> authentication" in the first drafts of the OAuth IPR document; because
> it was one of my comments on the doc:)
>
> 
>
> Here is an example usage. Again, this is more about leveraging the OAuth
> signature mechanism than trying to represent the whole OAuth flow.
>
> Currently at AOL we have a clientLogin API that allows a "client" (think
> destop app or mobile device) to authenticate a user and then access
> services at AOL. Basically, the authentication credentials are exchanged
> for a token that is used subsequently to access the APIs. The user's
> credentials are only passed to the AOL authentication service, over SSL,
> for validation.
>
> With the method suggested, the same validation could take place but the
> password would not be present in the request. Instead it would be used
> to sign the request. The request is only valid if the receiving
> authentication system can generate the signature using the password for
> that user.  The successful response of such a request would be the API
> access token currently used.
>
> Another possibility (the example from the initial discussion) is using
> this mechanism with TLS in order to return to the "client" a SAML
> Holder-of-Key Assertion. This is the same concept of exchanging one set
> of credentials for another credential (in this case a SAML Assertion).
>
> I realize that there are security issues with allowing a "client" or API
> based authentication mechanism, but there are certain cases where it
> provides a better user experience and the user is comfortable trusting
> the application/device.
>
> Thanks,
> George
>
> Chris Messina wrote:
> > Hmm. Historically the separation came from the way the communities
> > grew up actually. There were thoughts initially to make OAuth and
> > extension of OpenID but because I was wary of the politics within the
> > OpenID community, I pushed for keeping OAuth completely separate and
> > avoid having to do anything with authentication (so that it could be
> > used with OpenID, but would have its own adoption curve).
> >
> > The typo on the homepage was probably my fault, since, being the
> > identity n00b, I didn't realize the difference until after I went home
> > from the DevHouse where I put up the homepage after a couple beers. It
> > didn't change because (apparently!) no one else seemed to read it that
> > closely.
> >
> > Funny how these things develop -- not always out of explicit
> > intention, but just because of the time allotted to get the thing out
> > the door!
> >
> > ...as for your idea, George, I think I get it, and it sounds
> > interesting. Can you give a concrete example where that could be used
> > today?
> >
> > Chris
> >
> > On Wed, Jan 28, 2009 at 12:58 PM, Hans Granqvist  > > wrote:
> >
> >
> > Yep. The entire authentication/authorization discussion is sadly
> > muddled.
> > The OAuth/OpenID hybrid proposal is adding to the confusion.
> >
> > Sometimes I feel like we (people who have interest in the two
> > concepts)
> > maintain there is a difference to justify standards' existence,
> > even if
> > it's largely an academic difference with no pragmatic real meaning.
> >
> > Other times it feels okay that they should be separate. Just one
> > of those
> > things, I guess.
> >
> > For the longest time oauth.net  claimed OAuth
> > was for API authentication
> > and no one really noticed.
> >
> > The only thing worth being very strict about, IMO, is identity and
> > authentication. Never the twain should meet.
> >
> > It's HMACs all the way down anyway :)
> >
> > Hans
> >
> >
> > On Wed, Jan 28, 2009 at 12:02 PM, John Kristian
> > mailto:jmkrist...@gmail.com>> wrote:
> > >
> > > Yes, a digital signature can be used for authentication. SSL/TLS is
> > > one example. OAuth specifies some signing algorithms that could be
> > > used for the purpose.
> > >
> > > But it seems dangerous to extend OAuth to do authentication as
> > 

[oauth] Re: Authentication API protected with OAuth

[George Fletcher]

Thanks for this history Chris. I remember it still being "API 
authentication" in the first drafts of the OAuth IPR document; because 
it was one of my comments on the doc:)



Here is an example usage. Again, this is more about leveraging the OAuth 
signature mechanism than trying to represent the whole OAuth flow.

Currently at AOL we have a clientLogin API that allows a "client" (think 
destop app or mobile device) to authenticate a user and then access 
services at AOL. Basically, the authentication credentials are exchanged 
for a token that is used subsequently to access the APIs. The user's 
credentials are only passed to the AOL authentication service, over SSL, 
for validation.

With the method suggested, the same validation could take place but the 
password would not be present in the request. Instead it would be used 
to sign the request. The request is only valid if the receiving 
authentication system can generate the signature using the password for 
that user.  The successful response of such a request would be the API 
access token currently used.

Another possibility (the example from the initial discussion) is using 
this mechanism with TLS in order to return to the "client" a SAML 
Holder-of-Key Assertion. This is the same concept of exchanging one set 
of credentials for another credential (in this case a SAML Assertion).

I realize that there are security issues with allowing a "client" or API 
based authentication mechanism, but there are certain cases where it 
provides a better user experience and the user is comfortable trusting 
the application/device.

Thanks,
George

Chris Messina wrote:
> Hmm. Historically the separation came from the way the communities 
> grew up actually. There were thoughts initially to make OAuth and 
> extension of OpenID but because I was wary of the politics within the 
> OpenID community, I pushed for keeping OAuth completely separate and 
> avoid having to do anything with authentication (so that it could be 
> used with OpenID, but would have its own adoption curve).
>
> The typo on the homepage was probably my fault, since, being the 
> identity n00b, I didn't realize the difference until after I went home 
> from the DevHouse where I put up the homepage after a couple beers. It 
> didn't change because (apparently!) no one else seemed to read it that 
> closely.
>
> Funny how these things develop -- not always out of explicit 
> intention, but just because of the time allotted to get the thing out 
> the door!
>
> ...as for your idea, George, I think I get it, and it sounds 
> interesting. Can you give a concrete example where that could be used 
> today?
>
> Chris
>
> On Wed, Jan 28, 2009 at 12:58 PM, Hans Granqvist  > wrote:
>
>
> Yep. The entire authentication/authorization discussion is sadly
> muddled.
> The OAuth/OpenID hybrid proposal is adding to the confusion.
>
> Sometimes I feel like we (people who have interest in the two
> concepts)
> maintain there is a difference to justify standards' existence,
> even if
> it's largely an academic difference with no pragmatic real meaning.
>
> Other times it feels okay that they should be separate. Just one
> of those
> things, I guess.
>
> For the longest time oauth.net  claimed OAuth
> was for API authentication
> and no one really noticed.
>
> The only thing worth being very strict about, IMO, is identity and
> authentication. Never the twain should meet.
>
> It's HMACs all the way down anyway :)
>
> Hans
>
>
> On Wed, Jan 28, 2009 at 12:02 PM, John Kristian
> mailto:jmkrist...@gmail.com>> wrote:
> >
> > Yes, a digital signature can be used for authentication. SSL/TLS is
> > one example. OAuth specifies some signing algorithms that could be
> > used for the purpose.
> >
> > But it seems dangerous to extend OAuth to do authentication as
> well as
> > authorization. Better for OAuth to focus on doing one thing really
> > well.
> > >
> >
>
>
>
>
>
> -- 
> Chris Messina
> Citizen-Participant &
>  Open Web Advocate-at-Large
>
> factoryjoe.com  # diso-project.org 
> 
> citizenagency.com  # vidoop.com 
> 
> This email is:   [ ] bloggable[X] ask first   [ ] private
>
> >

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Authentication API protected with OAuth

[Chris Messina]

Hmm. Historically the separation came from the way the communities grew up
actually. There were thoughts initially to make OAuth and extension of
OpenID but because I was wary of the politics within the OpenID community, I
pushed for keeping OAuth completely separate and avoid having to do anything
with authentication (so that it could be used with OpenID, but would have
its own adoption curve).
The typo on the homepage was probably my fault, since, being the identity
n00b, I didn't realize the difference until after I went home from the
DevHouse where I put up the homepage after a couple beers. It didn't change
because (apparently!) no one else seemed to read it that closely.

Funny how these things develop -- not always out of explicit intention, but
just because of the time allotted to get the thing out the door!

...as for your idea, George, I think I get it, and it sounds interesting.
Can you give a concrete example where that could be used today?

Chris

On Wed, Jan 28, 2009 at 12:58 PM, Hans Granqvist  wrote:

>
> Yep. The entire authentication/authorization discussion is sadly muddled.
> The OAuth/OpenID hybrid proposal is adding to the confusion.
>
> Sometimes I feel like we (people who have interest in the two concepts)
> maintain there is a difference to justify standards' existence, even if
> it's largely an academic difference with no pragmatic real meaning.
>
> Other times it feels okay that they should be separate. Just one of those
> things, I guess.
>
> For the longest time oauth.net claimed OAuth was for API authentication
> and no one really noticed.
>
> The only thing worth being very strict about, IMO, is identity and
> authentication. Never the twain should meet.
>
> It's HMACs all the way down anyway :)
>
> Hans
>
>
> On Wed, Jan 28, 2009 at 12:02 PM, John Kristian 
> wrote:
> >
> > Yes, a digital signature can be used for authentication. SSL/TLS is
> > one example. OAuth specifies some signing algorithms that could be
> > used for the purpose.
> >
> > But it seems dangerous to extend OAuth to do authentication as well as
> > authorization. Better for OAuth to focus on doing one thing really
> > well.
> > >
> >
>
> >
>


-- 
Chris Messina
Citizen-Participant &
 Open Web Advocate-at-Large

factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com
This email is:   [ ] bloggable[X] ask first   [ ] private

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Authentication API protected with OAuth

[Hans Granqvist]

Yep. The entire authentication/authorization discussion is sadly muddled.
The OAuth/OpenID hybrid proposal is adding to the confusion.

Sometimes I feel like we (people who have interest in the two concepts)
maintain there is a difference to justify standards' existence, even if
it's largely an academic difference with no pragmatic real meaning.

Other times it feels okay that they should be separate. Just one of those
things, I guess.

For the longest time oauth.net claimed OAuth was for API authentication
and no one really noticed.

The only thing worth being very strict about, IMO, is identity and
authentication. Never the twain should meet.

It's HMACs all the way down anyway :)

Hans


On Wed, Jan 28, 2009 at 12:02 PM, John Kristian  wrote:
>
> Yes, a digital signature can be used for authentication. SSL/TLS is
> one example. OAuth specifies some signing algorithms that could be
> used for the purpose.
>
> But it seems dangerous to extend OAuth to do authentication as well as
> authorization. Better for OAuth to focus on doing one thing really
> well.
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Authentication API protected with OAuth

[John Kristian]

Yes, a digital signature can be used for authentication. SSL/TLS is
one example. OAuth specifies some signing algorithms that could be
used for the purpose.

But it seems dangerous to extend OAuth to do authentication as well as
authorization. Better for OAuth to focus on doing one thing really
well.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---