Meeting countdown: Jan 19 (today – week 0), Jan 26 (next week – week 1), Feb 2 (the week after – week 2), Feb 9 (WG Draft and Public Review vote – week 4)
We should strive for issue burndown and substantially complete specs by Feb 2 if possible – I may be calling on specific people to help close nitsy but not-very-substantial issues
Critique new wording (Core Sec 1.4.2, Sec 9.4, and impacts on Sec 3.6) and ensure it's sufficiently specified – e.g., the AS knows about resource IDs but the client doesn't, and the permission ticket can refer to multiple resource IDs, so is everything clear from that perspective?
Decide whether we need to be specific about AS implementation details (George's email)
Account for "previous RPT" logic
Shoebox: 246: Endpoint for collection of "receipts" and notifications of RS action in case of extraordinary behavior / 245: Location Constraints / 224: RS Notifies AS or RO of Access / 63: Audit logs to support legal enforceability / 24: Possible to audit host's compliance in giving access based on a legitimate active permission from the AM?
How many use cases?
Which are in our scope for V2.0 or out (e.g., separate modular specs that a V2.x could call out as an optional or required endpoint as part of the protection API or something)?
Is this in scope for V2.0 or out (e.g., a third-party extension that we could consider for a V2.x), considering the additional detail provided in email?