Eve and Thomas: Edit the spec and add swimlane diagrams showing flow options. (Meet on Friday.)
Quorum was reached.
Minutes of 2012-02-23 meeting APPROVED.
See relevant information:
In George's initial diagram, the "Access Alice's calendar with no token" means "with no RPT". His flow imagines that there is a new separate step where an empty RPT is issued, which would then require the requester to go back a bunch of times to get a RAT, get an RPT, start filling it with permissions, etc. This doesn't seem right, since the host shouldn't care whether the requester has a RAT or even an RPT yet when it tells the requester that it needs an UMA permission to get to this resource.
What if MyCalendar gets and conveys a permission ticket in all circumstances where there's insufficient permission (no token, invalid token, token with insufficient permission)? Then TripFollwr would be sent to the AM to rectify the situation regardless. Is there any danger in the permission ticket getting out into the wild? We can't see any, just as we couldn't before. It's a permission request ticket, not a permission ticket per se. Currently the host doesn't include anything identifying the requesting side in its permission registration process at the AM anyway (Section 3.4).
Once Roger/TripFollwr is told by MyCalendar that it needs to go to CopMonkey to get an RPT, TripFollwr could independently recognize the fact that it doesn't have a RAT yet for Roger with CopMonkey, and request it directly. So even though it has a permission ticket, it can't quite use it until it has a RAT in hand, and then it can go about trying to win the permissions it needs.
It seems very logical to get MyCalendar entirely out of the job of handling or caring about RATs, since it's not a party to that token (so to speak). So it's not just syntactic sugar/optimization to embed RAT issuance in the process of permission requests; it's an appropriate time and place with the appropriate parties at the table. Would it be possible for the permission request process to leverage any claims CopMonkey happened to collect while issuing the RAT, so that Roger isn't unnecessarily inconvenienced? We think so.
We really like the full separation of authentication and authorization. We have now fully mirrored an OAuth flow on the authorizing and requesting sides.
We edited George's diagram dynamically on the call; the result is here. We achieved consensus on this new approach, which will require a fair amount of spec work:
Let's close issue 49.
As of 28 Feb 2012, quorum is 6 of 11.
Non-voting participants:
Regrets: