Let's track the PII conference Nov 12-14 in Palo Alto.
Let's not meet next week.
No official comments have come in to date. Nat notes that repeating a review process until there's sufficient comfort with the spec is valuable. All other forums, including ISO, build this in.
Eve will attend. Nat will probably attend. Gil probably won't.
We adjusted milestone settings on various issues.
For issue #95, Maciej is interested to discuss it sooner rather than later. Marcelo is interested in the challenge of load-balancing one AS vs. another.
We discussed issue #83. Marcelo points out that if the RS doesn't do this right, it seems more like it's a broken RS vs. something we can fix in the spec. Nat comments that it might not be a privacy issue but might well be a security issue. Maybe it's more like a best practice, once we get more experience.
We discussed issue #37. It seems the "naive" method of simply re-registering scopes completely will work for now. In the worst case, an RS can redo everything.
We discussed issue #26. We'll leave it open, on the assumption that it may not be 100% closed by virtue the existence of the claim profiles spec.
We discussed issue #20.
Nat points out the quite often, location-dependent obligations need to be imposed, e.g. at Boeing for highly sensitive data. Gil also points out document redaction scenarios. There are consumer and IoT scenarios as well.
Gil often advises people not to use Obligations in XACML because it's such a mess. It can be hard to apply obligations in the right order etc.; that is, interpretation of them is not obvious. Some have talked about an obligations-handling service. Yikes!
However, it can be useful for the AS to convey various kinds of information to the RS, e.g. in/associated with the RPT. Eve notes that this kind of feature is eminently profilable as part of either the existing "bearer" RPT token profile, or new profiles that are XACML-style.
AI: Eve: Create an issue for Obligations-type communications and assign no milestone to it.
There are questions around the exposure of users' real names in error logs. So there's a need to pseudonymize/tokenize/"nickname" such PII while keeping the association. Zhanna will update us on her thoughts on this in email.