On Tue, Jun 26, 2012 at 1:54 AM, Lewis Adam-CAL022 <
adam.le...@motorolasolutions.com> wrote:
[...snip...]
> ** **
>
> I think the above just really drives home the fact that if OAuth is to be
> used for securing enterprise API calls in a post-SOAP world, something
> needs to be stated more explicitly. OAuth was not designed to provide
> authentication of the user to the RS. But it seems we all agree that it
> can be profiled to do so. Connect is supposed to address authentication,
> but only from the view of the client, and not the RS. Only the access
> token goes to the RS, so if we want to authenticate a user to the RS, then
> we’re back to OAuth, since Connect doesn’t intend to send the id_token to
> the RS. Nat mentioned that it “could,” but I haven’t seen that as part of
> the Connect specs thus far. ****
>
> ** **
>
> There is **clearly** confusion around whether OAuth is to be used as
> authentication or not, and I think this
>
thread has shown that. If I’m going to deploy OAuth for Authentication,
> then I really need a spec to point to (when my customers ask) that says it
> can be used that way, especially with all the “OAuth is NOT authentication”
> blog posts floating around in cyberspace these days.
>
Confusion is true. The fact is that OAuth by itself is incapable of
providing user authentication result to the resource server (nor the client
for that matter). It in fact is completely out of scope. OAuth is an access
delegation (aka authorization) mechanism. It has nothing to say about who
uses the token. Assuming the user of the access token is the resource owner
is a false assumption.
> ****
>
> ** **
>
> I’m thinking two things: ****
>
> **1) **it would at least be worthwhile to document this use case,
> and maybe the OAuth use cases draft would be a good place to capture it.
>
Starting from a stand alone use case would be good.
My impression (I may be wrong) is that your requirement is to be able to
(1) Log the user identifier of the person who is accessing the resource at
the resource server for the audit etc. purposes.
(2) Do the holder of the key so that the RS is sure that the person
accessing with the access token
is really the person.
(3) In addition, the RS may not be able to talk to AS directly.
[Well, this is one of my use case anyways.]
(4) In some cases, the client may not be able to communicate with AS
directly at the time of RS access. [ditto]
Are these correct?
FYI, (2) has been a work item for John Bradley for sometime.
For (1), (3), (4), OIDF's CX working group has been working on it.
The Working Group currently is dormant waiting for the Connect to finish
so that it can leverage it. (Good portion of Connect actually came from CX
work results.)
****
>
> **2) **maybe a stand alone, informational draft would also be a good
> idea, especially if we all agree that it’s only a profile of OAuth, and
> does not require any technical changes to the core draft. Something that
> talks outright about an enterprise-centric world, rather than the user
> RO-centric world that OAuth was really written around. This might give
> future generation of Enterprise folks like myself an easier time.
>
That's essentially what we are doing with OpenID Connect, though not
informational document but as a normative standard at OIDF.
Best,
Nat
> ****
>
> ** **
>
> ** **
>
> Thoughts?****
>
> -adam****
>
> ** **
>
> **
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
