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

Susan Morrow susan.morrow at avocosecure.com
Wed Mar 2 11:51:03 EST 2011

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)




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:

1.	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.

2.	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

3.	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.
4.	TR5 appears to include two separate elements:  truthful claims and
agreement to honor terms.

Do you think this should be broken into subsets?

5.	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. 
6.	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?

7.	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.
8.	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."
9.	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.
10.	I might add TR13:  Requesting Party trusts AM to protect Requesting
Parties authentication information in accordance with its advertised Service
Policy/Privacy Policy.

Thank you.




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:


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!


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

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

Jeff Stollman
stollman.j at gmail.com
1 202.683.8699

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

More information about the WG-UMA mailing list