AuthZEN Subgroup 1 (SG1) Charter

# AuthZEN Subgroup 1 (SG1) Charter ## Volunteering Participants: - Steve Venema - Eve Maler - David Hyland - Roland Baum - Alex (Babeanu? Olivier?) - Adam Rusbridge ## Background Using the XACML nomenclature, a PEP requests authorization decisions from a PDP using a 4-tuple of qualifiers: `Subject`, `Action`, `Resource`, and `Environment`. The PDP evaluates applicable policy and returns an authorization decision that is one of {`Permit`, `Deny`, `Indeterminate`, `NotApplicable`}. ### Current Information Model *(This text is extracted from our current AuthZEN API draft)* Subject : the user or robotic principal about whom the Authorization API is being invoked. The Subject may be requesting access at the time the Authorization API is invoked, or the Subject may be of interest in a Search API call. A Subject is a JSON object that contains any number of key-value pair attributes. An attribute can be single-valued or multi-valued. It can be a primitive type (`string`, `boolean`, ...) or a complex type such as a JSON object. Resource : the target of an access request. It is a JSON object that is constructed just like a Subject object. Action : the type of access that the requester intends to perform. There are common actions defined herein, or the action may be custom, which could be specific to the application being accessed or shared across applications but not listed in the common actions below. Action is a JSON object that is constructed just like a Subject or Resource object. Context : The Context object is a set of attributes that represent environmental or contextual data about the request such as time of day. It is a JSON object that is constructed just like a Subject, Resource, or Action object. In the (draft) AuthZEN "Authorization API", we use the keywords `subject`, `action`, `resource`, and `context` to represent this 4-tuple, where `context` corresponds to the `Environment` element of the XACML nomenclature. ### PDP Response *(adapted from current draft of AuthZEN spec)* The only valid responses from the PDP are a `decision` value of either `true` or `false`. However, there are valid reasons to allow the PDP to also include `context` in its reply to the PEP. This context could include reasons for a given`false` or `true` decision; it could also contain `advice` or `obligations` **(hereinafter called "A&O")** that the PEP **MUST** or **MAY** respectively enforce. ## SG1 Objectives SG1's charter is developing `advice` and `obligations` support into a set of normative text and examples to be incorporated into in the AuthZEN API spec (post Implementer's Draft 1). ### Out of Scope The AuthZEN excluding the idea of decision TTL and caching from the current spec development work. We may revisit this at a future date. We mention this here because such TTL and caching information would logically belong in the context part of a response from a PDP. The SG1 work should keep this in mind so that this information an other as-yet-undefined information can be extended in the `context` part of a PDP response without creating breaking changes. ## Some Key Questions: 1. The structure of A&O responses could be quite complex. Perhaps we can limit the complexity to cover a set of representative use cases to start with? 2. In a sense, the A&O responses levies decision-making requirements on the PEP, potentially blurring the conceptual line between PEP and PDP. Can we (and should we) put boundaries on the expectations of what decision making a PEP is expected to perform? 3. Does it make sense to somehow incorporate the concepts of `indeterminant` and/or `notApplicable` in PDP responses instead of just `false` and `true` we currently specify? Or should we retain the `true` and `false` only, and include additional data in the a `constraints` JSON sub-object of the PDP response that covers the `indeterminant` and `notApplicable` use cases? ## Proposed Sequence of Work 1. Develop a set of representative use cases (preferably a small number) 2. Specifically address the above questions 3. Develop proposed normative text and examples for incorporation into the AuthZEN API spec.