[WG-UMA] Draft minutes of UMA telecon 2010-06-24
sakimura at gmail.com
Thu Jul 1 11:43:06 EDT 2010
Looks like I need to understand more about what is included in the
initial metadata when Alice is registering the Flixre to her AM.
Also, FYI, AB has both push and pull mode. It started off with push
only, and after feedback from the community, we have added pull mode.
Both are valid use cases.
On Thu, Jul 1, 2010 at 9:48 AM, Eve Maler <eve at xmlgrrl.com> wrote:
> Sorry to take so long to respond to this... It's really good input,
> particularly regarding having flexibility to do both push and pull models. I
> realize we may not have you on tomorrow's call, but going back and forth in
> email can help a bit...
> Thinking out loud here about policy-setting use cases:
> Let's say it's Monday. Alice uploaded a file to host Flixr just before
> introducing it to her AM; her motivation in doing the introduction might
> have been to "protect" exactly that photo, right away. So the AM is going to
> want to know things about her Flixr photos right away. (Christian has been
> arguing for this for a while, leading to his early proposals to push the
> resource registration information even before the user has finished the
> introduction, for efficiency!) It sounds ideal for the AM to pull the info
> from Flixr right away if possible, given your logic.
> On Tuesday, Alice happens to be fooling around with AM settings and finds
> out she can make host-specific policies. She associates a blanket policy
> with everything at Flixr. If she goes to Flixr on Wednesday and uploads more
> photos, she would expect those photos to have that policy apply to them
> without her having to visit the AM again. Would Flixr have to push
> information about the new photos?
> On Thursday, Alice is once again exploring new AM features. It turns out she
> can both tag individual resources that each host has told the AM about, and
> she can even make use of tags that she earlier attached to those resources
> directly at the host, such that she can attach policies to particular tags
> and possibly even turn everything tagged a certain way into resource baskets
> automatically. So the photos that she had already tagged on Flixr as being
> "vacation 2010" are reflected in the AM interface. If on Friday she visits
> other hosts (that are already UMA-protected) and uploads/creates/tags new
> resources as being "vacation 2010", wouldn't they want to push information
> to the AM as soon as each of her login sessions is done?
> I guess what I'm asking is, over and above reasons of network efficiency and
> firewall realities, do we have *high-level* use cases for both push and
> pull, and if so, is there a conflict in trying to have both given the
> network/firewall situation?
> On 24 Jun 2010, at 5:12 PM, Nat Sakimura wrote:
> Sorry that I could not attend this meeting. I was too tired to do a meeting
> I did not have an appetite to even watch the worldcup game so that describe
> how tired I was ;-)
> A comment inline wrt Pull and Push model.
> On Fri, Jun 25, 2010 at 5:27 AM, Eve Maler <eve at xmlgrrl.com> wrote:
>> As of 3 Jun 2010 (post-meeting), quorum is 6 of 10.
>> Catalano, Domenico
>> Gamby, Randall
>> Hardjono, Thomas
>> Maler, Eve
>> Moren, Lukasz
>> Non-voting participants:
>> Aaron Titus
>> Anna Ticktin (staff)
>> Maciej Machulak
>> Joe Andrieu
>> Christian Scholz
>> Tom Holodnik
>> Roll call
>> Aaron was invited by Mark Lizar to join. He is an attorney in D.C. He is
>> the privacy director for the Liberty Coalition. He is running a National ID
>> Watch project. And he's also spending effort on Privacy Commons, which has a
>> user-centric rather than a data- or corporate-centric.
>> Quorum was not reached.
>> Approve minutes of 2010-06-17 meeting
>> Deferred due to lack of quorum.
>> Action item review
>> 2009-12-03-4 Eve Open Add terms-negotiation scenarios to Scenarios
>> 2010-05-27-3 Eve Pending Find and distribute info on the new proposal for
>> OAuth signing. It seems to have been broken out from the core OAuth spec.
>> 2010-05-27-4 Eve Pending Ask Dave Crocker for help with Step 1 user
>> stories. No progress.
>> 2010-06-17-1 Christian, Eve Open Work on the conversion of the core spec
>> and the dynamic registration spec to xml2rfc. In process.
>> Focus meeting report and discussion
>> Hold another focus meeting on 30 Jun 2010?
>> Not sure yet. Eve will coordinate with the absent folks and let everyone
>> How are we doing on our "rough-out Step 1 by end of June" goal?
>> We think we're doing pretty well.
>> In the SMART implementation, the AM publishes XRD material that the host
>> retrieves in order to get fully introduced to the AM by the authorizing
>> user. This is pretty much the way our current spec says to do it.
>> Nat has proposed that the dynamic registration of the host with the AM
>> (outside of the context of any user) use the AB model ("pull") and
>> techniques (possibility of signed metadata etc.). He will try to harmonize
>> all the proposals and present us with new thoughts soon. At the same time,
>> Eran H-L is working on the somewhat similar "OAuth Discovery", which we know
>> we will have opinions about. Our plan of record is to submit an I-D
>> specifically about this, to influence that work. We believe Eran is planning
>> to work on OAuth Discovery right about now, so time is of the essence.
>> Our Step 1 involves an overarching goal of having the user get the host
>> and AM to trust each other for (respectively) authorization and hosting
>> services in the context of the user. Should we stick to the word
>> "introduction" for this process? Yes; using the word "registration" seems to
>> be too confusing. We should reserve "registration" (if that's even
>> appropriate? that registration involves discovery but that's not the whole
>> story) for processes having to do with a host dynamically signing up for
>> credentials at an AM. This has an impact on the spec-writing we do
>> (Christian and others, please note!).
>> In fact, we think the general problem to be solved is "automated
>> self-registration of a a client account with unique login credentials at an
>> authorization server"! So maybe that can be the definition of some shorter
>> name. <smile.gif>
>> RRAPI (resource registration API)
>> Nat has proposed that the host statically store its resource details on
>> its own site and have the AM "pull" it, vs. our current proposal (which is
>> to "push" the information in an OAuth-protected manner). Eve and Randall
>> suspect that pushing is better, since there will be less latency and network
>> traffic that way: the host could push the info whenever the user updates
>> info on the host, vs. the AM polling/pulling periodically even if
> In AB, the "pulling" happens when the user lands at the AM (during
> We decided on the design pattern after some discussion with huge portals and
> search companies:
> (FYI, AB also has a "push" mode especially for the "clients" that are behind
> the firewall. That actually was the original proposal on the table.)
> Suppose the push by the "host/client" happens and immediately the AuthzUser
> is redirected to the AM where AM is a geographically distributed huge server
> farm. The chances are that the "client" and the "AuthzUser" is landing on
> different servers on different continent, that the cross server sync is not
> yet finished so that the AuthzUser encounters an error. This is clearly
> undesirable. If it were a pull after the AuthzUser landing, it does not
> happen. The AuthzUser is always served realtime successfully because it is
> the server that the AuthzUser landed who pulls the request_url. The
> request_url also has a fragment that is shat256 of the request file, so the
> server knows if it has been retrieved already and shared across the server
> farm, in which case, the server does not have to fetch it reducing the
> network traffic. On the other hand, if the request file is changed, even if
> the request_url without the fragment is not changed, the fragment changes
> and thus the AM MUST re-fetch.
> AB never do polling either.
>> nothing has changed. And the host access token authenticates the
>> information just as much as the pull model seems to. We're willing to be
>> convinced otherwise, but we'll assume a push model as our default approach
>> for now. Maciej had floated an idea (not on the list yet) that the RRAPI
>> could variously use either a push model or a pull model. Lukasz thinks he
>> likes the pull model best at least for dynamic registration, and maybe also
>> resource registration. We have some more thinking and testing to do here.
>> Third-party-asserted claims, "identity tokens", trust model
>> Eve reviewed the way in which our Step 2 enhances OAuth, namely, with the
>> possibility of the AM asking the requester to pass along some claims. And
>> she reviewed the three use cases we've been exploring:
>> Alice-to-Dopplr (the most "OAuth-like" use case; Alice may want Dopplr to
>> adhere to her own imposed policies)
>> Alice-to-InfoUSA (InfoUSA is acting on its own behalf; Alice is in an even
>> stronger policy position here)
>> Alice-to-Bob (the nature of claims requested here would likely be
>> We acknowledge that there may be arbitrary numbers of intermediaries in
>> between the end-to-end parties to an UMA-forged contract, and their pairwise
>> terms of service may be looser than the UMA contract, thus "leaking" value.
>> Our discussion at IIW taught us that the advent of modern trust frameworks
>> may help here, if we can assure that all the UMA-compliant parties
>> interacting together are members of the desired framework? Further reading
>> for those interested in the legal subteam discussions:
>> Legal Considerations doc (fledgling)
>> Comments on doc from Jeff Stollman, and much further list discussion
>> Notes from early discussion with Tom Smedinghoff (expand the "quoted
>> IIW discussion led by Jeff S
>> The FTC has recently been concluding that the current regime of requiring
>> "notice" isn't working very well. Aaron comments that his Privacy Commons
>> work is trying to increase useful transparency of the consequences of
>> sharing. We want to make sure to build the "offer and acceptance" pattern
>> (that defines contracts vs. notice) into UMA. And, therefore, when the
>> requesting party is a person, we want there to be some positive action on
>> the part of the person – e.g., clicking "Yes, I agree to these terms" –
>> which will generate the returned claim.
>> Regarding the Alice-to-Bob sharing scenario, there are particular
>> technical complications having to do with technology, user experience, and
>> sheer complexity of having lots of moving parts. Interestingly (to put it
>> mildly!), Domenico has proposed a solution for identity claims that involves
>> Bob having an UMA-protected claim (!!) that Alice's AM can pull (!!). For
>> the same reasons that we tout UMA for allowing requesters to pull data
>> directly from an authoritative source, pulling a claim about Bob from the
>> authoritative source is also powerful.
>> Randall wants identities that are both strong and cheap. It seems a bit
>> too early to force a solution here, but Eve hopes we're getting close to the
>> "Identity Singularity" and need to pay close attention to see which emergent
>> solutions solve our requirements.
>> Next Meetings
>> ??? Possible focus group meeting on Wednesday, 30 Jun 2010, at 7-8am PT?
>> (time chart)
>> WG telecon on Thursday, 1 Jul 2010, at 9-10:30am PT (time chart)
>> Eve Maler
>> eve at xmlgrrl.com
>> WG-UMA mailing list
>> WG-UMA at kantarainitiative.org
> Nat Sakimura (=nat)
> Eve Maler
> eve at xmlgrrl.com
Nat Sakimura (=nat)
More information about the WG-UMA