[WG-UMA] New trust model draft up on the wiki

Eve Maler eve at xmlgrrl.com
Wed Mar 2 13:55:11 EST 2011

Great comments and responses! My additional thoughts below.

On 2 Mar 2011, at 8:51 AM, Susan Morrow wrote:

> Hi Jeff,
> Hope you don’t mind me jumping in, I’m sure Eve will reply too, but I just have a couple questions / comments (my questions in blue below)
> Susan
> From: wg-uma-bounces at kantarainitiative.org [mailto:wg-uma-bounces at kantarainitiative.org] On Behalf Of j stollman
> Sent: 02 March 2011 14:27
> To: Eve Maler
> Subject: Re: [WG-UMA] New trust model draft up on the wiki
> A few comments on the Trust Model:
> I would substitute the word "trust" for "relies on" in Relationship column, since we are modeling trust, not reliance.  They are not synonymous.
> There does seem a direct connection, certainly legally between the term ‘relies upon’ and trust, as you need to trust to rely on – don’t you? The trouble with the word ‘trust’ is that is a open to interpretation under different contexts.

I don't have a dog in this fight, particularly. If using fewer (inherently somewhat squishy) words is better, that argues for "trusts". If the concept of "relying party" has successfully crossed the chasm from the strict federated ID world to the generic trust world, "relies on" could be useful. (Ah, see below too...)

> While TR2b is a reliance, there is no trust involved.  If the User does not introduce the Host to the AM, the Host experiences no exposure.  Therefore, I don't think it needs to be specified.
> I think this is assuming that the user will be introducing the host to the AM

Yes, maybe we can make clearer that in a single TRn series, the later ones depend on the antecedent ones for "layers" of TR formation -- sort of preconditions.

> In TR3a, aren't the referenced activities the AM's Service Policy (inclusive of their Privacy Policy)? Might we want to coin the term Service Policy to refer to the advertised commitments of an entity to another entity.  This is the inverse of a TOS which is the demanded commitments of third parties.

Great suggestion! We can flow that to the other similar TRs too.

> TR5 appears to include two separate elements:  truthful claims and agreement to honor terms.
> Do you think this should be broken into subsets?

Yeah, great idea. Indeed, there are two protocol points for TR formation: supplying claims, and accepting a token. (And our recent discussions about scoped access show just how separated these may be.)

> I would restate TR6:  To respect the boundaries of (advertised/negotiated) data usage constraints for the requesting party's authentication information, committed to by the User.

I'm not sure I understand. Do you mean that "anyone using the requesting party's authentication information" is subject to these constraints? Is this a slippery authentication slope (or is it exactly what the new Virginia bill is trying to cover)?

> As in point 1 above, I am not sure that TR7a represents trust as much as it is a reliance.  It is not clear from what is stated that there is any exposure to the Host if the AM does not provide a functional API -- unless the issue is a "secure" API that would prevent others from impersonating the AM.
> That’s a good point re spoofing the AM but doesn’t that then give weight to the trust relationship between the AM and Host being reliant on a functioning API?

I think I'm starting to see the difference now between soft "reliance" and formal "trust". I was just trying to be inclusive in the table, so as not to miss something. Maybe we can identify and discuss all these specific cases together, and maybe relabel them appropriately?

> I would rewrite TR7b to, "To accurately convey the User's desired access scope information."  I also think that the trusting party is the User, not the Host.  There is no exposure of Host information at stake.  It is the User's information.  If the AM fails to honor the User's specification, it is the User who suffers.  The Host is merely following orders.  It is not responsible for an AM failure here if it took advertised precautions in authenticating the AM.

Good point.

> In all subelements of TR8 I again think that the trusting party is the User not the AM.  For example in TR8a, it is the User who trusts the Host to honor the AM's TOS.  The AM is not responsible for the selection of the Host, the User is.  Therefore, it is the User who must trust the Host.  The AM is "just following orders."

I'd argue for keeping TR-8a as it is, since hosts get credentials from AMs entirely apart from the user context, and the AM may impose (e.g.) out-of-band requirements on hosts prior to this step. (The user subsequently does trust the host in the AM context (TR-1b).

For the others, can't we say this is a kind of user-to-AM delegation of responsibilities? The user is largely absent from the UMA-compliant interactions, so the AM has to represent them and the host has to interpret this as an act of representation (agency?). Hmm, the AM could be said to be an authorizing user agent (looking at the later requesting-side wording)??  Wheels within wheels.

> As with TR8 above, I think that TR11 reflects the User's trust, not the AM's.  The AM does not make a decision.  Only the User makes a decision in its establishment of directions for the AM.

Same questions arise...

> I might add TR13:  Requesting Party trusts AM to protect Requesting Parties authentication information in accordance with its advertised Service Policy/Privacy Policy.

We've got a TR-13 below, but this could be TR-12x or something, going by the existing naming pattern.


> Thank you.
> Jeff
> On Wed, Feb 23, 2011 at 7:10 PM, Eve Maler <eve at xmlgrrl.com> wrote:
> Thanks to Susan's efforts with Rainer and the "trust gang" on the Fed Interop WG side, and comments from Tom Smedinghoff and Paul Bryan on early drafts, and everyone's input from last week's call, we've put together this revision of the trust model:
> http://kantarainitiative.org/confluence/display/uma/UMA+Trust+Model
> Hopefully this will turn out to be a productive direction.  The TODOs section has a long wishlist of additional content we could add as our understanding deepens.  Please take a look at this doc, and the TODOs list, for tomorrow's call.  Thanks!
>        Eve
> p.s. Domenico, you may recall our previous work to represent the Legal Considerations info in graphical form. If this looks like a more solid conceptual model to work with, does it spark any "graphical thoughts" for you?
> Eve Maler                                  http://www.xmlgrrl.com/blog
> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
> _______________________________________________
> WG-UMA mailing list
> WG-UMA at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma
> -- 
> Jeff Stollman
> stollman.j at gmail.com
> 1 202.683.8699

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20110302/741168b5/attachment-0001.html 

More information about the WG-UMA mailing list