Omri: As we have started working on the obligations profile it became clear missing the context coming back on the evaluations call. Karl's proposals also ran into this challenge. We are lacking feilds in the req/resp payload to do this - probably split context from the 'context' about options to be used for negogiations. Likely needs to be a 1.1. Obligations need this to be done 'right'. Laying an obligations profile on a 1.1 which bakes in an additional feild called 'options' on all endpoints. Need implementor input on how much this would break eg Protobuf + JSONSchema.
AlexB: Why does it need to be 1.1?
Adding feilds to a contract can break a v1.0 de/serializer.
Wouldn't have to do that if options were part of context
Omri: Evaluations doesn't contain the context.
Omri: Footgun - send an evaluations call, in the top level context set the obligations, but the array-item level will overwrite these.
Michiel: The evaluations override logic is confusing (but well defined). Not an obligations specific footgun.
AlexB: Lets start with evalution - which has context. Then scale it up to evalutions and search.
Michiel: Agree and moving out search also makes sense - not sure how that maps. Moving foward focus on evalution.
Karl: Need to draft the extensibility profile for AuthZEN - setting the rails which obligations rides on.
Jeff: Sounds good - should also be disocovry endpoint metadata so the PEP can know about the support
AlexB: The PDP doesn't support anything then the PEP can just deny
Karl: Would be useful to return an error code/message
Jeff: The way OIDC and Oauth work - if the server part of the exchange doesn't support something the client needs, then the client disregards it.
Michiel: We define context as an open feild - we never spec'd what the PEP does if it doesn't know what to do with it.
Karl: This is the signally mechanism for the PEP<>PDP processing semantics - if you can't process the obligations you must fail close. Its not if you can't understand it.
Jeff: For an obligation PEP client there needs to be a way for it know
Karl: The serialization issue - returning and ignoring of fields needs to handle not just throwing away and permit.
Karl: Will do a draft 2 and bring it into a WG doc
Certification
Naming - Core, Batch & Search
Timelime
Certify for:
Each of the searches
Properties support
Request for implementers to test-out the certification test-suite. Edmund looking for any feedback on bugs issues etc.
[Edmund] Ideally we'd need at least 3 implementations, or 1 per plan minimum
[AlexO] will message Gert to ask about Topaz
[DavidH] Possibly also
[Edmund] "properties" tests, should they be named differently? "Properties" are optional parameters now, configurable.
[AlexO] Just certify for Core, Bulk and Searches...
[Edmund] End of September/early October target. Likely October release.
[AlexO] Cost to be certified.
[Edmund] $700 for members, $3500 for non-members
Profiles
[AlexO] Vote Next Week. COAZ MCP binding, currently being mapped to the latest MCOP Spec.