[cap-talk] Why tokens have short lifetimes in OAuth-WRAP

Kenton Varda kenton at google.com
Thu Mar 18 20:18:52 PDT 2010


It strikes me that this pattern would be necessary even in capability
systems in cases where Alice wants to grant Carl access to a resource held
by Sally, but Alice for some reason has no ability to talk to Sally
directly.

But if Alice can talk to Sally directly, then the whole pattern seems kind
of pointless.

Ah, but here's a perhaps more realistic case:  Say that Sally is a big,
distributed system with thousands of computers, and Alice wants to grant
access to a resource held by all of them without having to communicate with
each one.

Still, it seems like there are easier ways to solve this.

On Thu, Mar 18, 2010 at 8:20 AM, Karp, Alan H <alan.karp at hp.com> wrote:

> David Barbour wrote:
>
> A far better response to my question than what I got from the WRAP folks.
>
> The disconnect is based on the approach we used for our ZBAC implementation
> where the service is its own root of trust.  In our scheme, the token
> originates with the service and is delegated to the authorization service.
>  The authorization service delegates a separately revocable token to the
> user, and the user presents that token when making a request.  In our
> approach, a revocation request goes to the service, not the authorization
> service.  Hence, there is no communication needed for the service to find
> out if a token has been revoked.  That approach can be adapted to WRAP.
>  Since the token is specific to the service, the authorization service can
> notify the service when a token has been revoked.
>
> ________________________
> Alan Karp
> Principal Scientist
> Virus Safe Computing Initiative
> Hewlett-Packard Laboratories
> 1501 Page Mill Road
> Palo Alto, CA 94304
> (650) 857-3967, fax (650) 857-7029
> http://www.hpl.hp.com/personal/Alan_Karp
>
>
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20100318/99405cf3/attachment.html 


More information about the cap-talk mailing list