As of 18 Nov 2011, quorum is 7 of 13.
Non-voting participants:
Regrets:
Eve |
Open |
Set up webinar dry-run meeting. |
|
|
Maciej, Lukasz, Mario |
Open |
Send draft webinar slide content by COB Friday. |
|
|
Eve |
Open |
Draft webinar slide deck by dry-run time. |
|
|
Eve |
Open |
Create a Fraunhofer AISEC FAQ from Mario's slide content. |
|
Quorum was reached.
Minutes of 2011-11-17 and 2011-12-01 meetings APPROVED.
Don't forget to tweet, FB, and G+ the news! If you can, retweet the @UMAWG status update, so that it also simultaneously advertises that Twitter handle:
http://twitter.com/#!/UMAWG/status/144805389194629120
Planning to be on the webinar to present: Frank (which part?), Eve (intro), Maciej/Lukasz (SMART impl), Mario (Fraunhofer impl), Paul (why become a host: "distributed access management is hard") – also Sampo/Luk?
Planning to join the webinar live (vs. listen to the recording later): Thomas, Domenico, possibly George.
Let's plan on a webinar dry-run next Monday at 7am PT.
The use case explored by the Fraunhofer implementation is photo sharing. The SMART implementation is exploring a personal data store (PDS) use case.
Lukasz has begun to fill in a new SMART implementation FAQ. He'll fill this in over the next few days. A suggestion for a new question: Is SMART planning to add support for policies that work with more than just Facebook friend lists?
Last week, the WG went through some issues.
Regarding issue #3, should the AM always return a policy URI regardless of whether the host is creating, reading, or updating a resource set? Lukasz says yes, and this is what SMART does. George describes it as a "pseudo-deep link into the AM". Do we have to say anything about this as a security consideration? We should make clear that the host MUST not expose this policy URI to anyone other than the user on whose behalf the resource set was registered, and the AM SHOULD NOT send policy URIs that expose in-the-clear policy details to the host. Thomas will incorporate all this. Let's now definitely close #3!
Regarding issue #8, Thomas will close the issue and incorporate the result. This closes Paul's related AI.
Regarding issue #16, can we just get away with continuing to say the host SHOULD register a permission? Let's do that, and wait for feedback from various implementers. Thomas will close the issue with no action.
MOTION by George, second by Frank: Submit the latest UMA core draft, as edited according to 2011-12-08 telecon instructions, as IETF I-D 02. APPROVED.
Thomas suggests an UMA get-together at RSA in February. Eve and Frank will also be around that week, and maybe others. Let's discuss at the next telecon.