Not sure why you want to pull the OAuth token parameters from the Kerberos token.
Are you envisioning the Protected Resource is a Kerberos Client? On Mon, May 24, 2010 at 9:31 AM, Thomas Hardjono <hardj...@mit.edu> wrote: > > I'm still a newbie to the OAuth and WRAP discussions, so please bear with > me. > > In Section 2.2, draft-ietf-oauth-v2-05 states that the access token is > basicaly an opaque structure to the client, but which can have some > "internal structure" (having meaning to the authz server and resource > server): > > ] Access token strings can use any internal structure agreed upon > ] between the authorization server and the resource server, but their > ] structure is opaque to the client. Since the access token provides > ] the client access to the protected resource for the life of the > ] access token (or until revoked), the authorization server should > ] issue access tokens which expire within an appropriate time, usually > ] much shorter than the duration of the access grant. > > I was wondering how true this is? > > I want to use a Kerberos v5 ticket as the token (base encoded). The OAuth > Client need not understand this structure, but could simply pass it down to > the Kerberos-client (in the OS or in the browser). > > Then within this token (now a Kerberos ticket), the ticket fields would > contain matching entries (as far as possible) to the OAuth token parameters > (eg. expires_in, token_secret, etc). > > For the cryptographic tokens (Section 5.3), I would then use the > session-key in the ticket to compute he HMAC. > > Would this work? Any suggestions? > > /thomas/ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
