Quorum was reached.
MOTION: Andi moves: Approve the minutes of UMA telecon 2014-08-28 and read into today's minutes all the notes from all intervening non-quorate telecons. APPROVED by unanimous consent.
We have invented a method of solving for "token authentication" of ROs and RqPs. Roland reports that he already supports token authentication, so we should be good to proceed. It would be great to start reporting results in the wiki before IIW.
Mark D is giving a lightning talk on UMA at Nordic APIs in a couple of weeks. Andi is giving a talk on UMA in Copenhagen in December as well. Sebastian Rohr is giving an UMA talk in German and we hope he'll offer his slides back for sharing. Eve was invited to speak on UMA at APIdays in Paris in December, but can't.
Mike suggests trying to have supplementary APAC-friendly times to meet, particularly if we can entice Nat to join those calls. This would be great but depends on Nat confirming attendance, which is difficult. So for now we'll proceed with the plan shown below.
Eve's proposal lets the AS have a lot of implementation-based control over RPT management. Maciej notes that returning 201 - Created isn't really right if the RPT isn't a new one. This relates to the questions Eve poses about what to do if the client puts the "wrong" RPT in the request for authorization data, or an invalid one, or whatever. We actually already have that problem in the current version of the spec – it says it responds with 201, but it doesn't mandate the creation and return of a new RPT.
The client shouldn't be "in control of" a true RPT resource at the AS the way an RS is truly in control of a registered resource at the AS, so we don't want to get into POST vs. PUT vs. whatever. It's just asking for authorization to access something. The AS should be able to manage authorization data and RPTs however it wants. Therefore, some kind of vague success response is all that's required. Would 200 - OK do? Or 204 - No Content in the case of keeping the same RPT or 201 - Created in the case of a new one? We think it should be defined.
Then the only thing we're missing is if the client sends an invalid RPT to the AS. Do we need to add an invalid_rpt error code? Since a good AAT along with a good ticket could still let the AS issue a new good RPT, maybe all that's required in this case is simply some "advice" that the RPT supplied wasn't good. How could we provide a warning, vs. an error that the provided RPT in the request was "not good", and either was invalid as presented or was revoked by the AS upon presentation? For example:
HTTP/1.1 201 Created
Content-Type: application/json
{
"rpt": "sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv",
"warning":"RPT in request was invalid."
}
Mark thinks an error response is better than this. Maciej agrees. People comment that it feels wrong to silently accept a wrong RPT over and over. So do we invent a new error code?
We did agree that the error code not_authorized_permission is okay to change to not_authorized.
Deferred!
As of 2 Oct 2014, quorum is 8 of 14.
Non-voting participants:
We will hold all-hands meetings (calling the roll) through the fall and early winter as much as possible; voting participants please attend! You can subscribe to the UMA calendar (and ask the chair to send you an event invitation) to see the times in your local time zone. Keep in mind that when the clocks change, we experience "summertime skew"; our home time zone is Pacific so non-US meeting times may shift.