...
- Upcoming meeting opportunities and calendar planning
- Trust Elevation TC preso
- Skip meeting on Sep 1118?
- KI workshop in Utrecht
- IIW in Bay area
- IRM Summit KI workshop in Dublin
- PII in Bay area
- Public review status and disposition of any comments to date
- Open issues
- Interop planning
- AOB
Minutes
tbs
Attendees
...
Welcome to Pete Buonora of BJ's Wholesale Club. He's an enterprise architect. He has OAuth-related and IoT-related areas of interest.
Upcoming meeting opportunities and calendar planning
- Trust Elevation TC preso
Eve presented to them this morning. It seemed productive. Potentially they might be in a position to write some third-party profiles for claims-gathering or other stuff on UMA eventually. Gluu has, of course, written a "trust elevation profile" to constrain authorization when the authentication is too weak.
- Skip meeting on Sep 18?
Yes, skip it. Eve can't make it, and Mike will be speaking at API World (on UMA) the previous day.
- KI workshop in Utrecht
This is Sep 4 and 5. Mark is preparing a presentation with his Kennisnet colleague, and they're also coordinating with Maciej, who will be doing a demo. Domenico is contributing as well.
- IIW in Bay area
Mike is going (regardless). He's on record as not liking F2F interops. He'd rather do a session where we present interop results.
Sal is going, with some of his developers.
Currently Roland is booked to attend, starting on the 29th.
Let's not do a publicized F2F interop, but keep it lightweight. The main opportunity is to get more backing for efforts and resources to flow from the (completed) OpenID Connect to UMA. As many implementors as possible should try and go. Let's make this a F2F meeting with an implementation focus, starting on the 29th.
Mark can't attend.
Marcelo might be able to attend.
Eve can encourage sufficient ForgeRock folks to attend (including herself).
Adrian will attend, and we hope for a lot of implementation coming from his and MIT's corner of the world.
Dave will attend; they're in the process of implementing.
- IRM Summit KI workshop in Dublin
- PII in Bay area
We'll check in on these closer to the dates.
Public review status and disposition of any comments to date
We've received one IP declaration. More coming on this soon.
Issue 63 - audit - see Zhanna's proposal in email
We reviewed the proposal. This seems similar to a typical "transaction ID", not primarily for the purpose for auditing but for support. Is this envisioned as optional? as transparent to the developer unless something goes wrong? Zhanna does conceive of this as a kind of session or transaction ID. It can capture that "this user at this time" did something. For analyzing the case where someone seemed to break a sharing rule, the theory is that it's especially important for a protocol like UMA to have something like this.
For example, if the AS suspects a malicious attack, it can ask the RS or client: What do you see for this audit ID? There's no need to see log files in bulk, just the relevant log entries correlated with this specific audit ID.
A feature like this could be positive or "confusing" for privacy! It's suggested that we should try to take on a goal of strengthening privacy through it. It would be possible to encrypt private information, such as PII, with a public key in the logs; this might help. When it's needed to see the information more broadly, e.g. a judge orders the logs to be made available, then the information could be decrypted. Adrian's concern is about "roles" being revealed in the logs. E.g., the RO's role, or the RS's internal role not usually exposed across institutions. The role of an admin or other privileged user is accounted for in Common Criteria.
What does "UMA exchange" mean? It seems to mean something like a single end-to-end set of requests and responses among all three parties.
What does "upstream/downstream RS" mean? It has to do with interactions with, e.g., OpenID Connect entities and OAuth entities in a larger ecosystem.
Eve would like to see some concrete use cases and requirements stated so that we could test whether the proposed technical solution meets them. The Binding Obligations spec, for example, was motivated originally by trying to apportion responsibility when something goes wrong in a loosely coupled ecosystem. E.g., did Alice write the policies wrong (or make some other error in interfacing with the AS)? Did the AS not respect her policies properly (or did it operate maliciously)? Did the RS not respect the resulting permissions (assuming the "bearer" RPT profile) (or did it operate maliciously)? Did the client exploit a security hole? Did the RqP misrepresent itself in providing claims?
Zhanna had also proposed something similar to the OAuth WG. The goal would be to interact with log files of other similar systems (like OIDC) in a friendly way.
Discussion of these issues was deferred.
Attendees
- Eve
- Mark
- Andi
- Dave
- Sal
- Adrian
- Maciej
- Ryan
- Roland
- SteveO
- Zhanna
- Marcelo
- Thomas
- Mike
- Ann
- Pete
Regrets:
- Abhi
- Gil
Next Meetings
- All-hands meeting Thu Aug 28 9-10am PT (time chart)
- APAC-friendly focus meeting Wed Sep 3 4-5pm PT/ Thu Aug 7 8-9am JPN / Thu Sep 4 9-10am AUS (time chart)
- ?? Focus meeting Thu Sep 11 9-10am PT (time chart) – Eve regrets
- FocusNo meeting Thu Sep 18 9-10am PT (time chart) - Eve, Mike regrets
- All-hands meeting Thu Sep 25 9-10am PT (time chart)
...