This is a Quorate meeting.
6 of 27 present; quorum not reached.
As previously announced in email, Eve Maler was confirmed as Chair, Paul Bryan as Vice-Chair and Technical Spec Editor, and Hasan Akram as Use Cases Editor. Thanks to all for their participation in this ballot.
Deferred due to lack of quorum.
AI: Eve: Create a doodle poll to establish a time for a ProtectServe overview.
Eve has pursued inquiries with the IIW organizers, and they may have a room to offer us. Let's try and request an afternoon-long meeting on the Monday. We could also plan to host an IIW session sharing the results of our work to date. (Do we need a "walk-through IPR agreement" in the form of a sign outside the door?)
AI: Eve: Check on IPR considerations around public(ish) F2F meetings.
Hasan has sent email proposing a way of contributing to the scenario document: we can use hashtags to alert him of our ideas in email, or contribute content directly. Note that his email may have reversed the senses of our choice of scenario (high-level) and use case (lower-level) terminology.
The goal is to identify the key differences between scenarios/use cases, so that we don't add a lot of duplication.
Eventually our technical specs will need to turn into IETF Internet-Drafts. So possibly we should write the spec using xml2rfc. Alternatively, we could edit the document in Confluence, which allows for more natural collaboration and gives us some content management (e.g. tracking changes) by default. Maybe there's a way to export to xml2rfc or raw HTML from Confluence.
AI: Paul: Research technical spec formats and their pros and cons.
We discussed two scenarios but haven't decided on a disposition of them yet.
Eve reviewed this scenario and its use case in detail. Some aspects that make this scenario special/unique (are these on the way to becoming requirements?):
We began to discuss this. Some aspects that make this scenario special/unique:
We discussed the possibility of not "muddying up" this scenario by having the multiple resources aspect in it. Should we pick another example, maybe something more realistic taken from today's OAuth world? The real-world example of chained location services that all read and write to each other is cool, but also scary.
AI: Eve: Revise the photo set scenario to be more realistic.
We definitely need to add a scenario, probably focused VRM or VPI situations, that takes into account distributed SPs for pieces of data coming from multiple sources. We don't have an owner for this yet, though Iain and Eve may be contenders; they will be discussing this offline.
(Following is an example of the hashtag in use...)
#scenario: Authorizing access to a set of multiple resources hosted on distributed SPs.
Alan 
noted that there's a big problem in identity systems of having the same data in multiple places, since they may go out of sync or go stale. [Eve notes later: We're trying to mitigate this by making point-of-use data retrieval more consistently reliable than using data on hand.]