Thomas: Normatively xref to the Trust Model spec from the protocol spec and make the 2012-04-05 spec changes, getting input from Lukasz. Due by next Tuesday morning.
Quorum was not reached.
Trey is from UnboundID. It's largely an infrastructure vendor for service providers and telcos, and they provide various aspects of identity management, including databases and higher-stack functions. His past included a lot of LDAP and UDDI work, and currently he works on SCIM. Their interest in UMA is about how carriers can manage release of user attributes.
Deferred due to lack of quorum.
It was a success, though quieter than in the past. Interesting themes: trust model advertising, interop commitment, and potential carrier interest in location claims.
Let's consider the chat series concluded for now, and we'll do ad hoc ones or even weekly ones later when warranted.
Pamela is still planning to create that "UMA1" namespace. We'll develop feature tests after that.
Domenico is pushing forward on the "triangle of trust" concept, and has drafted a short user guide that discusses what sort of accreditation system UMA deployers could participate in. Identity assurance plays a role.
Sal reviewed the Trust Model spec and has no significant comments at this time. One soft comment is that it's a little tricky to use the "levels of assurance" language. Should we switch to "levels of confidence" instead? At least soften the mention. Also, it's time to try out a normative reference to the Trust Model from the protocol.
Trey has a greenfield on UMA development; they've already hardwired OAuth and OpenID Connect. We should put a premium on getting the protocol spec to absolute readiness for new developers as quickly as possible.
We agreed to create a separate endpoint. The AM config data will need a change to add a rpt_endpoint. This makes the Authorization API be more interesting , since it will have two whole endpoints.
This new endpoint just issues RPTs (and eventually could revoke them). This enables requesters to manage RPTs the way they wish: They could have more than one per "user-tuple", they could (eventually) revoke them if the user leaves the requester's service, and if they lose an RPT, they can get another one.
We'll need a new section between 3.4.3 and 3.4.4 (and related intro revisions) explaining that the requester needs to get an RPT before starting to add permissions to them.
Rationale: Treating the RPT much more like an OAuth-style token is better for future-proofing (like revocation) and doesn't prematurely optimize the UMA flow. There is a small performance hit in doing the extra back-channel call; we'll be listening for implementer and deployer feedback on whether there's heartburn over this.
We should get explicit feedback on this decision at IIW before implementing it.
As far as we know, our issues list doesn't have any other hugely high-priority items on it! Everyone please review and say if you think differently.
Thomas will update to remove discovery stuff, as desired by the OAuth folks.
As of 25 April 2012, quorum is 6 of 10.
Non-voting participants:
Regrets: