# Meeting Notes 2024-06-18 ## Attendees 👉 Add your names here @omri David Hyland David Brossard Patrick Parker Dima Postnikov Atul ## Agenda - Spec cleanup - Implementer's Draft: details and process - AOB (all other business) ## Actions * Changes to PR (@omri) * Make RFC9493 (subject identifiers) OPTIONAL for specifying ID of subjects * "Custom Actions" -> "Other Actions" * Reason ID -> string * Address other minor feedback in the PR comments ## Open issues * How does the mandatory nature of subject type/ID intersect with distributed identity? (ex: age attribute is sufficient to validate whether the subject can vote, vs requiring identity resolution) ## Notes OG: New Authorization Spec. - Introduction Left as is. - Features in Search APIs left similar - Substantive Changes in information Model - Subject Identifiers RFC9493 - Some other attributes might be required. options to use 9493 as a baseline DB: Agree-Disagree - if things are defined then we should use them - do not agree as 9493 includes a complex type which makes creating an Auth Request harder. Dont make it mandatory. include is as a value and then put it on the PDP to resolve. Prefer to keep it simple OG: RFC9493 has a few parts. JSON Types ok - Format - Types Identifier formats v Principal Types - Even it fwe use Formats we still need to define Principal Types. - Issuer Subject. AT: The spec 9493 - subject ID not includes as a way to express subjects, reason why he did not include in original spec was that the doc was more for internal type comms where richness was required. Has since realised the value and included PR. OG: Question is if we want to make it mandatory. PP: Can see DB is looking for simplicity. If looking at use cases e.g. Multiple IDP scenario what do we solve.? if a user has multi email alias. OG: RFC 9493 does have email alias PP: How do we move away from very specific subject - how to we move to a more generic model e.g. DID Privacy preserving type model. OG: Having more opinion in the standard would help. To increase interoperability we need to be more opinionated. DB: Developer life is made harder if more generic - opinionated helps simplify. Was looking at Cerbos - they have an opinionated model which helps with development testing etc. However, RFC9493 is a good guide but should not be mandatory AT: TX tokens spec went through this same discussion. They started with RFC 9493 and then moved to a more just a sub field in the JWT - in high volume systems it is easier to have a simple model to reduce complexity and workload. Volume Related concerns - more complex makes it harder and increases load. OG: proposal is to keep it simple and not make it mandatory. AT: Originally thought it might work so included in the PR - but has since realised that doesn't need to be mandatory OG: Happy to roll it back - for subject should we have a type and It AT: **AGREE** Good with Type and ID. OG: JSON object? can be string or object. Q: do we want to be any more specific? DB: Type or ID ? AT: Balance Flexibility - 9493 a good way - from interop there may be a requirement for profiling OG: Will clean up the PR - will keep it simple. **AGREE** type mandatory - can be string or RFC9493 style identifier. AT: Has outstanding reviews - will submit - not significant for discussion right now. OG: Some things Like IP address were proposed, but not needed as we can just add as attributes. AT: PARC - would things like Device ID IP just go into context OG: **AGREE** - could go into context DB: XACML should these go into ENV or User? 4 bucket model is enough - if you want IP address etc they can go into any of these. AT: Keep it optional and these attributes can be added to any. DB: if we involve the PEP then it may get opinionated... When we onboard gateways then we may have an HTTP resource profile of AuthZen. AT: Spec can give flexibility then we can have profiles on top. Probably not a problem. DB: ... e.g. if we have Policy - do we then need policy templates AT: would be up to each PDP to do DB: Converter could transform easier if we agreed on attribute names. AT: Flexibility v OOB interop. OG: 5 tuple required - Subject Type - Subject ID - Action Name - Resource Type 0 Resource ID. Allows need expression of you allow additional attributes we have flexibility to add anywhere. We have the flex to add to the core fields. AT: **AGREE** OG: Will roll back the MUST to a MAY re RFC9493 Action Values: REST style pattern is limited - perhaps have Actions as reference strings to enhance interop - Common Action value section or Roll back AT: Thought he had the Spec a CRUD ... OG. types may have been changed ... DB: did not add can... AT: liked common action values - Predefined values are good here. OG: We have Action Evaluation . Response single decision field. Section in Additional Context in response. (advice & obligations) Reason Field - Objects. Suggestion to make IDs in to Strings. DB: Q as why the IDs were numbers. AT: would have liked to have meaning in ID... wanted a number to support enum? DB: if context if JSON - AT: Should add enum to help .. PP: Custom Actions - would prefer to not use "Custom" AT: use Other actions. OG: **DECISION**: Will use Other actions. OG: Clean HTTPisms and moved to Transport Renamed HTTPs bindings - semantics are not exactly REST - so we have changed to HTTPS bindings. AT: Because we are using JSON we are committed to HTTP: OG: There are gRPC mappings - Cerbos team have raised - there are vendors that want to use other bindings (e.g. Aserto, Cerbos). AT: Will we have other binding section OG: **AGREE** - in future we can add other bindings. AT: Do we want to validate ? Do we want to get Cerbos to validate OG: Not required for Implementers Draft - but should be something we aspire to AT: **AGREE** DB: **AGREE** with AT - XACML wanted a formal def but XML ties to XSD etc. AT: keen to see how they might defined protobuf mappings. OG: **AGREE** - keep JSON and move away from Protocol Agility DB: **AGREE** AT: Don't need to add a section right now. OG: Error Responses added 400-403 AT: These are PDP PEP only? 200 only transport OG: Spec to make sure of use of 200 only for transport. DB: Comment has been made - ISTIO/ENVOY driven by response - doesn't like this. conflating layers. Do we need a flag to change mode of response? Doesn't like the idea AT: Most API gateway provide an extn. OG: Most GWs have response filters to do what ever needed: PP: Doesn't like the idea of using Transport OG: Leave out of spec. JD'M: Why ID is optional for resource? OG: Getting something to work for ReBAC 5 tuple - there was a scenario to ask does Alice have the Perm Read on Books. Valid Scenario. OG: not required to specify ID of principle DB: Good Point - ID is mandatory - ID Anon? even if ID is mandatory in request. AT: Probably needs more thought.