Twitter has an interesting use case that may become common: one client needs to
delegate access to another client. Similar to the 'modify' method where the
scope of the access token can be modified, the 'delegate' method allows a
client to request delegation to another client (the delegate). Here is some
proposed copy for the request:
type
REQUIRED. The parameter value MUST be set to delegate
client_id
REQUIRED. The client identifier as described in Section 3.4.
client_secret
REQUIRED if the client was issued a secret. The client secret.
refresh_token
REQUIRED. The refresh token associated with the client.
delegate_id
REQUIRED. The client identifier of the delegate
scope
OPTIONAL. The scope the client is requesting for the delegate.
secret_type
OPTIONAL. The access token secret type as described by Section 8.3. If
omitted, the authorization server will issue a bearer token (an access token
without a matching secret) as described by Section 8.2.
There a couple of choices for the flows for how a successful delegation is
conveyed to the delegate. The AS could return a delegation code that is similar
to a verification code and the delegate acquires an access token similar to
3.6.2
Alternatively, the AS could return an delegation token that is used similar to
a refresh token to obtain an access token and refresh token.
Do people think this is worth adding to the spec? It seems to be a simple
addition and allows us to standardize what is emerging as a common capability.
-- Dick
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
