Yep, we need to take care of that too. What I'm getting at is that it seems
like we need a better story about identity and 'immediate' in OAuth which seems
to be more about the use cases of the OpenID Connect proposal than the OAuth
core proposal. However, since these use cases are very important to many of the
participants here in the context of implementing *OAuth* (not OpenID), we
should provide some support.
What I'm thinking is to take the 'immediate' parameter out, and write a simple
OAuth identity extension spec where it will be included, as well as the
requested 'username' parameter (or whatever we decide to call it). It will not
include any discovery (which is probably going to be another spec), just how to
establish and verify identity using OAuth once you know where the token
endpoint is and have client credentials (registered).
But back to my original email, what are the use cases for 'immediate' without
identity?
As James pointed out, a client can generally use the immediate parameter
to offer "a bit of personalization if it can provide it silently".
Having that in mind, I see the following scenarios:
Classical OAuth
A classical OAuth client would probably have its own user management and
use OAuth to get access to a end-users resources on other sites. It does
not need to know (and probably shall not know) the user's identity on
the other sites. The immediate parameter could be used w/o identity in
the following situations:
- the client does not want to store refresh tokens and tries to aquire
an access token after login
- the authz server does not issue refresh tokens, but stores end-user
authorizations and issues access tokens based on it
- the client is authorized automatically by a security policy (company
internal applications)
OpenID Connect
In this context, the OAuth services is used to obatin the end-user's
identity. So how should the client know the identity upfront? This would
be comparable to an OpenID RP knowing the user id before issuing the
authentication request.
The immediate parameter works the same way as the openid.mode
"checkid_immediate". Typically the client will try to acquire an
end-users identity, if already established, in order to (optionally)
personalize the site. We do this for several portal sites (w/ our
proprietary SSO protocol). If this fails and the end-user enters a
protected region of the sites afterwards, user authentication is
enforced by ommiting the immediate parameter. Yes, if two users use the
same computer, the "wrong" identity could be used here. But that's, from
my point of view, a characteristics of single sign on. That's why single
sign-on should be accompanied by single logout.
My conclusion: There are several use cases where the client does not
need (or is unable) to know the user's identity but could use the
immediate mode.
In contrast, I think the username is useful in several situations w/o
the immediate mode. For example, if the client already possesses a token
for a particular user and wants to acquire another token for another
resource of that particular user. The client could ensure the users
identity match by passing the username to the authorization flow.
regards,
Torsten.
EHL
-----Original Message-----
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Sunday, May 23, 2010 2:38 AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] 'immediate' without identity
Are there use cases for the 'immediate' parameter where a companion
parameter for identity (e.g. 'username') is not needed or required? The
purpose of the 'immediate' parameter is for the authorization server to
authenticate the end user via some automatic means (usually a cookie) and
check if an access token was already issued for that end user / client
identifier combination.
This parameter is only useful when the client is already familiar with the
end user (not the first time it seeks authorization), in which case, it should
pass that information along to make sure the same user is logged into the
authorization server.
If all the use cases require both, we should include both and make one
required if the other is present.
EHL
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
How does the client determine the end-user's identity (at the AS) in the
initial authorization transaction? Will you introduce a respective response
parameter?
regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
