HI, I was looking at draft-ietf-ace-oauth-authz-04, specifically the client-to-AS section — I am trying to determine if it is possible to use this OAUTH-based model to implement attribute-based authorization (ABAC). The client-to-AS section of this draft refers the reader to section 4 of RFC 6749, which provides a “client-id” (good) and a “scope” to include in an authorization request.
In addition, it looks like the ACE draft adds to this the “aud” and “cnf” parameters. I’m trying to map this client-to-AS request to a traditional ABAC authorization request which asks the question “Identity <A> wants to perform action <B> on resource <C>” … is this allowed ? (allow/deny response) In one of the ACE draft examples, it uses the “aud” field to include the name of a sensor “tempSensor4711” - this could be the “resource” of the ABAC request, and the “client ID” (RFC 6749) could be the “identity” I’m missing the type of operation or “action” that the client is trying to perform on a resource (“read”, “write”, “something else, hopefully extensible”) — would this be the “scope” parameter ? I did see section 8.2 of the draft where it discusses a registry of parameters which might allow additional parameters to a client-to-AS request, but I was looking for a way to do ABAC without having to register anything. I’m specifically asking about obtaining an access token to be used later by a client accessing the actual resource. Has anyone tried combining draft-ietf-ace-oauth-authz-04 with ABAC systems ? Thanks! Randy _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
