Tuesday 9-10am PT

Dial-in and screenshare: http://join.me/findthomas

Calendar: http://kantarainitiative.org/confluence/display/uma/Calendar

(if you are currently not being invited to WG meetings and want to be, or the reverse, let me know)

Attending: Eve, Robert, Justin, John, Cigdem, Prabath, Mike, Domenico, Maciej (quorum!)

Our current substantive open issues look like this:

• #290 (Generality of RReg spec?) and #296 (Out-of-the-box profiling for tight AS-RS coupling): This is a biggie. Current proposal (for which I hope to have some more details by call time!) is to consider a different way of modularizing the specs. A group consisting of me, Mark L, Maciej, Andi, and Cigdem talked about this further in London last Monday and there was a pretty strongly favorable impression.

Eve reviewed her approach. Implied in the refactoring is two “operational modes”, that is, it would be possible to use the extension grant without using the federated authorization piece.

Justin suggests that this is a 2.1-phase action, on the theory that it’s almost certainly backwards compatible. Mike likes the approach and is supportive of the suggested timeline. So commit to only going as far as backwards compatibility allows? Yes.

Justin estimates that a 2.1 would be a 6-12 month effort. This sounds like a long time to Eve. :-) A big motivation is adoptability of even the 2.0 specs as they are, so she’d like to try the refactoring sooner.

Before we make a decision, Eve agrees to create a second, more detailed proposal that amounts to draft specs on a branch that can be examined for viability. She’ll do this by Apr 21.

• #294 (Consider a proof-of-possession option for the RPT): This topic is broader by now, including token binding etc., and we suspect this all might "just work". This just needs to be analyzed a bit. Prabath, you were going to take a look -- can you, please, and write up?

Prabath sent a nice writeup summarizing the state of play.

Justin: RFC 7662 (token introspection) notes, in an appendix, that there’s — presumably — an extension being written to finish the unfinished PoP piece.

Some options for our purposes:

1. Say nothing, since we incorporate (and profile) 7662.
2. Point explicitly at this language so that there is a mention of PoP.
3. Point explicitly at this language and add commentary regarding the need for extensions etc.
4. Define an extension ourselves at this juncture.
5. Mention in an appendix, a la 7662, the places where PoP would affect UMA but not do the work. This is like 2 but is more hands-off.

Discussion: Eve’s rationale for no. 2 or 3 (prior to Justin’s suggesting no. 5) is that mentioning proof of possession in the spec would give implementers something to hang onto to answer their questions. Cigdem points out that we do mention PoP, in Sec 6.1.1. However, this is actually a different meaning, referring to the RqP’s proof, not the client’s proof, so should we remove this usage of the phrase and stick to “holder of key” instead (SAML-like)?

We have consensus around no. 5. Eve proposes putting a new subsection in Sec Consid, discussing security properties of the RPT, modeling the language after the 7662 language. Let’s do that.

Speaking of Sec 6.1.1, it really has two attacks in it: innocent Bob/malicious Carlos but also malicious Bob handing off the RPT to his malicious friend Carlos. There’s very little we can do about the latter other than legal enforcement remedies. (This has been called “ABC” for the Alice-and-Bob Collusion attack.) Note that the OAuth WG has rejected this as a form of attack.

Some options:

1. Do nothing. Rationale: OAuth has chosen not to dignify the ABC attack.
2. Clarify that 6.1.1 is about innocent Bob, and if Bob is malicious, these mitigations are largely ineffective, but the premise of an access token is that the receiving side MUST keep it secure.

No appetite for no. 2, so we keep the status quo.

• #295 (When a requesting party needs to withdraw their access): This touches on downscoping and token revocation, and thus could use some analysis. Justin, this could use your eyeballs in particular, but it's really for everyone.
• #298 (Reconsider whether ticket should be on all redirect-back AS responses): Justin and Cigdem have been commenting on this one and seem to have consensus so far that we're okay, but it could use more eyeballs. But another related issue has come up about the appropriateness of not_authorized as an error that we could consider.

Deferred to Thursday.