Assertion Profile/ refresh token

[Dirk Balfanz]

Hi guys, 

someone brought this up in the discussion today, and I think they are right: The assertion profile should return a refresh token (in section 5.2.4). 

Here's why: chances are the assertion is a SAML or OpenID assertion that can only be re-obtained by having the user talk to their IdP. In other profiles, we have the refresh token precisely so the user doesn't have to be involved every time the access token expires. To support the same goal (the user should not be involved whenever the access token expires), we should also have a refresh token in the assertion profile. 

Thoughts?

Dirk.

[George Fletcher]

+1 :)

[Dick Hardt]

There is no user in 5.2. If the assertion used expires, then the
Client will need to obtain a new one. (how the Client obtains
assertions is out of scope)

In 5.2, the Authorization Server is acting as an STS, translating from
some assertion to an Access Token the Protected Resource understands.

We have refresh tokens in profiles where there is a User (5.3, 5.4,
5.5)

Note that if a User may authN to a Web App with a SAML token in 5.4,
how the user authN is out of scope of WRAP

George had mentioned that a profile where a Rich App could acquire an
Access Token from the Authorization Server by presenting a SAML token
on behalf of the User. If someone wants to write that up, that would
be fabulous (assuming I understood what George intended)

(please move the rest of this conversation over to OAuth WRAP WG!)

[Brian Eaton]

> (please move the rest of this conversation over to OAuth WRAP WG!)

(CC'ing both groups until George joins oauth-wrap-wg)

> In other profiles, we have the refresh token precisely so the user doesn't have to be involved every time the access token expires.

I don't expect the SAML profile to be used very often when a human
being is involved. If we've got SAML and a user in the picture, we're
almost certainly using the web SSO profile of SAML. Note that in that
case the client *never sees* the SAML assertion. All they know is
that they popped open a web browser to get user approval.

I do expect the SAML profile to be used in cases where no human being
is present, e.g. a cron job. For example:

- cron job wakes up, needs access to data
- local authentication context (e.g. kerberos, unix session, role
account password, IP address, ssh keys, or other magic security dust)
is used to talk to a SAML IdP
- SAML IdP returns a SAML authentication message
- SAML authentication message is swapped for an access token.

So no refresh token is needed; the ability to get long-lived access to
user data is provided by the local authentication context.

Cheers,
Brian

[Dirk Balfanz]

On Fri, Nov 6, 2009 at 9:46 AM, Brian Eaton <bea...@google.com> wrote:

> (please move the rest of this conversation over to OAuth WRAP WG!)

(CC'ing both groups until George joins oauth-wrap-wg)

> In other profiles, we have the refresh token precisely so the user doesn't have to be involved every time the access token expires.

I don't expect the SAML profile to be used very often when a human
being is involved.  If we've got SAML and a user in the picture, we're
almost certainly using the web SSO profile of SAML.  Note that in that
case the client *never sees* the SAML assertion.  All they know is
that they popped open a web browser to get user approval.

I do expect the SAML profile to be used in cases where no human being
is present, e.g. a cron job.  For example:

Makes sense. 

Thanks.

Dirk.