# Attendees
- David Hyland
- Atul Tulshibagwle
- Darin McAdams
- @davidbrossard
- Mans Hakansson
- Rifaat Shekh-Yusef
- Elie Azerad
- Pieter
- Roland Baum
- Bjorn Hjelm
- @alexbabeanu

# API review

## API comments

- Omri's: remove `X-` convention:
- Makes sense to have a request ID. It's optional. Correlate with PEP log. Use standard header or register a new one. Rifaat: research on the side, get back to it. +1 from Darin.
--> **A.I.**: _Requires research : Atul + Darin + David (XACML side)._
- Response ID should be also in the response header
- Roland: doesn't necessarily make sense, HTTP is synchronous, also seems redundant but optional is ok.
- Pieter: HTTP= transport layer: should the requestID be part of protocol or can we reuse smthg ? Are we re-inventing the wheel?
- David: FAPI has this x-fapi-interaction-id . But Alex: here's the "x-" again
--> Add recommendation: is implementing FAPI + AuthZen, then just use FAPI's x-fapi-interaction-id.

- Omri's comment: Array vs JSON object ("id" : "value"):
- Atul: intent: it conveys the name of the attributes being requested.
- Roland: What about complex structures? Atul: AttribNames is optional.
- David: this is misleading. Object can be both subject + resource. We need:
- Can i view Med record 123?
- Can I view Home Address?
- Darin: we went straight into the deep end, ABAC, etc... No content or use-cases. We will need to tackle it, but seems like a "big bite" right now.
- Pieter:
- "id" and "type", why "type"? Is "id" not unique? David: we don't want to dictate what the ID should look like. Different types have different ID formats.
- Should id and type be grouped together? Is it always going to be "Type" and "id"? David: they are already grouped.
- Atul: type is optional. it could come up in a search query.
- David: queries are Access request: yes/no, others can be searches (which resources can Alice see?).
- Roland: it's the typical search with permission Pb. David: seen solution returns in terms of a filter: you can search if...
- Roland works if structured data, doesn't work if permissions are random. Cannot see 1 record out of a million, doesn't work there. 3 strategies:...
- Rifaat: we're going to the deep-end, we need to step back.
- Eli: we're just passing objects, do we need to care?
- David: in XACMl the key isn't in the spec. Schema of user object is not in the spec. As long as the object in the request matches the policy, it's OK. But when customers implement XACML they ask: what attributes do I use?? There is merit to predefined attributes.
- Alex: if we go that route, we can look at schema.org, but would hate to have to do that.
- Atul: there's Subject, Actions, Resource. The subject should be the same as the RFC9493, can be used to describe objects. Resources is what we're describing right now. Would prefer a subject.action tuple for requests. David: We need context too: subject, action, object, context.
- David, what about authorization "stuff" coming in a token, is that part of the context?
- Omri: structure token as the subject is valuable.
- David: Ip address: environment or user attribute? Answer whatever you want to do as long as it makes sense?
- Atul: should this be an opinionated spec? David: being opinionated may simplify adoption.
--> **A.I.**: _Should we be opinionated?_
- Darin: opinionated ==> we're choosing a specific domain.
- Omri: would be good to be able to pass a JWT also.
- Roland: adding "context" is a good idea. But
- Atul: resources and subjects should have the same structure.
- David: in XACML, a resource must have a category. In Cedar it could be anything. An object be anything.
- Omri: we're discussing the payload. We can use generic objects to use as anything, but then we need to be able to label these as needed. 2 systems: stateless (xacml) vs stateful (Zanzibar, data in the authorizer). We should be able to support both ways. bare bones or complex.
- David: request = subject,action,object,context
- Roland: discussion =in use-case doc:
--> **A.I.**: _which ones should be mandatory?_
- Omri: can pass NULL context, object could also be optional for coarse grained.
- Darin: there are situations like that
- Omri: we need some bridge from old to new
- Darrin: AWS is the biggest authz system. "We've had to solve all these". Spent the last 2 years talking to customers. Conclusion: API and looks slightly different. If we model this way, then we won't be able to do some use-cases. Value in giving an overview of what AWS does?
- Omri: best way to go through the doc --> Atul: tackle high level questions first. Getting familiar with Cedar seems required before Darrin's session.
- Omri: more structured call? Atul: let's start with Cedar and go from there. Darin please send us some links.
-
# @davidbrossard's notes:
User object: could be a subject or could be a resource
E.g. Can Alice, the ldap admin view Bob in the LDAP tree?
Two types of questions:
1. access eval - Binary yes/no question
Can Alice view record 123?
2. Open ended-search
Which records can Alice view?
Which records of type 'medical record' can Alice view?
The current spec defines subject, action, and object.
be able to pass in not only simple things like strings but also structured content e.g. a JWT
Agree to add context category
Opinionated spec vs. generic spec? Pros and cons?