[WG-UMA] FW: trust model

[Susan Morrow]

Hi All,

 

Rainer has come back with some suggestions, etc. regarding the Trust Model – I’ve answered his queries in blue but you may be able to elaborate more?

 

Susan

 

 

Just in answer to some of your queries, I’ve added some info below in blue

 

- Patrick suggested that we substitute "liable actor" by "asserting actor", because asserting actor was already coined somewhere, and the asserting actor might not be liable in a legal sense with lower LoAs.

 

OK I can change that, but we may have to change in the UMA outline too as its specified as such there.

 

- TR-1 What does "COPS" stand for?

 

It’s the Common Open Policy Service for communicating the policies between the host and the AM  -using a PDP and PEP (the Host and AM respectively)

 

- TR2/TR3 "policy application/enforcement": It is probably clear from the context that this is the access policy. However, if we combine the various bits and pieces of the complete TF, this context will be lost. Therefore I would suggest to cal this the user managed access policy, short UMA policy.

 

OK I think that should be fine and I understand your logic

 

- TR-4 Entity AuthN without context includes humans as well - I would suggest Service AuthN as more precise term

 

OK will do

 

- TR-8 "Cross recognition of users" -  who recognizes what?

 

It must be via programmatic authentication – in which case should it be rolled into entity auth as you suggested above?

 

- Susan

 

[Eve Maler]

Thanks to Susan for persevering on this task!  Some comments and questions below. I'd like to discuss these on Thursday's call, if we can make sure at least Susan or Rainer will be on the line.

For folks who are new to Rainer's methodology for documenting trust models, you can find more info on the Kantara Federation Interop WG wiki where the work is taking place:

http://kantarainitiative.org/confluence/display/fiwg/Identity+Federation+Constellations+and+Use+Case+Overview

We're borrowing and extending the general concepts and terms they've developed over in that group, but the UMA situation is  a little different because we're not describing a classic "identity federation" with the classic three parties. In fact, it's more like describing a classic "PDP/PEP" topology than anything (think "XACML" vs. "SAML"), with an added dash of spice because the parties are meeting dynamically (instead of being statically configured inside a single comfortable administrative domain, as with enterprise access management...).

First big question/comment area: Applying Rainer's idea of building a catalogue of pairwise trust relationships, I like Susan's initial table, which currently lists TR-1 through TR-8. Questions on this:

- Does it make sense to distinguish the different things being relied on in separate TRs for the same pair of actors, or should they be considered as multiple elements of the single trust relationship between them?  E.g., TR-3 and TR-4 both refer to some aspect of trust between the host and requester. Is it better to combine them, since all trust between them gets forged through the exact same process?

- BUT... Another way to distinguish the relationships would be temporal. Is it useful to split some of the actors into "untrusted" and "trusted" phases? For example, the requester/requesting party spends a considerable amount of time interacting with other UMA parties before it's actually given any access authorizations, and (say) the AM should be liable for such authorizations yet. Should we treat this as a whole other "actor"? (I don't think any other parties deserve this distinctive treatment, but could be convinced otherwise.)

- Given that the trust runs in a single direction (relying -> liable/asserting), should we fill out a full set of logical TRs accounting for trust running in each direction, and then if any of the TRs happen to be trivial, saying so?

- Since our protocol deals with endpoints but our "legal considerations" make a distinction between a requester (tool) and a requesting party (legally responsible party), should the actors here reflect both tools and responsible parties, or just one, or just the other? My best guess is that only the latter should be covered, with all other side-relationships (such as in the Sharing with Airplanr graphic example in our Legal Considerations doc) being outside the scope of UMA. (BTW, I'm not sure if "RP" in TR-7 and TR-8 means "relying party" or "requesting party" -- probably best to spell out since we don't have a traditional relying party actor.)

- So, making guesses about the answers to these questions, should we have the following list of TRs?

Host relies on AM

AM relies on Host

Untrusted requesting party relies on AM

AM relies on untrusted requesting party

Trusted requesting party relies on AM

AM relies on trusted requesting party

Authorizing user relies on AM

AM relies on authorizing user

Untrusted requesting party relies on host

Host relies on untrusted requesting party

Trusted requesting party relies on host

Host relies on trusted requesting party

Untrusted requesting party relies on authorizing user

Authorizing user relies on untrusted requesting party

Trusted requesting party relies on authorizing user

Authorizing user relies on trusted requesting party

If we can come to a common understanding of the right TR list, then we could catalogue the various needs for authentication, authorization policy, security of other sorts, and privacy that obtain for each of these relationships.

Second big question/comment area: I'm not sure we need to create a constellation for each and every user story, because they're not all at the same "level". I wonder if our "sharing profiles" might be the right level, e.g., person-to-person sharing vs. person-to-self sharing etc., since the liability picture probably changes with each one. The Legal Considerations doc linked above begins to address these distinctions, but maybe this is the right place to get really specific with it. If people think this is a good idea, then I suggest we go through and catalogue the scenarios in our Scenarios and Use Cases doc just along this dimension (maybe Thomas can help with this??). Then the set of examples for each sharing profile could illustrate the trust issues unique to each.

Finally: A few responses to the thread below...

On 8 Feb 2011, at 10:39 AM, Susan Morrow wrote:

Hi All,

 

Rainer has come back with some suggestions, etc. regarding the Trust Model – I’ve answered his queries in blue but you may be able to elaborate more?

 

Susan

 

 

Just in answer to some of your queries, I’ve added some info below in blue

 

- Patrick suggested that we substitute "liable actor" by "asserting actor", because asserting actor was already coined somewhere, and the asserting actor might not be liable in a legal sense with lower LoAs.

 

OK I can change that, but we may have to change in the UMA outline too as its specified as such there.

I'm fine with either, though "liable" is more generic and therefore perhaps more suited to our non-identity-federation case.

 

- TR-1 What does "COPS" stand for?

 

It’s the Common Open Policy Service for communicating the policies between the host and the AM  -using a PDP and PEP (the Host and AM respectively) 

(I hadn't heard this acronym before either!) Note that we communicate "policies" if you mean the strict definition, which is something like "authorization decision" (Paul Bryan may want to weigh in on this, as I know he has strong terminology opinions here). But for UMA, it's out of band to communicate policies that are generically stated (e.g., "requesting parties asking to see this photo must prove themselves to be citizens of the U.S.") and not yet applied to any particular request for access.

- TR2/TR3 "policy application/enforcement": It is probably clear from the context that this is the access policy. However, if we combine the various bits and pieces of the complete TF, this context will be lost. Therefore I would suggest to cal this the user managed access policy, short UMA policy.

 

OK I think that should be fine and I understand your logic

My various comments above may impact this. We probably want to settle on exactly what we mean by "policy" first, then decide the universe of TRs we want to have, then go from there!

 

- TR-4 Entity AuthN without context includes humans as well - I would suggest Service AuthN as more precise term

 

OK will do

Good idea. Maybe service authn vs. user authn would be nice and clear? This is where my old "authentication model" doc may possibly come in handy; you're certainly welcome to steal text from it if that helps.

 

- TR-8 "Cross recognition of users" -  who recognizes what?

 

It must be via programmatic authentication – in which case should it be rolled into entity auth as you suggested above?

Programmatic authentication sounds like service authentication to me -- an example of such authentication would be an UMA actor in the role of an OAuth client authenticating to an UMA actor in the role of an OAuth authorization server.

But the only way in which I'd say we currently have "cross-recognition of users" is in an access token (we have two of these, a "host access token" and a "requester access token"), which functions like a federated identifier/pseudonym that the token holder can use to talk about "the same user" as the AM is talking about. Is that what you guys mean?

Eve

Eve Maler                                  http://www.xmlgrrl.com/blog

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

[Eve Maler]

Oops, error below...

On 13 Feb 2011, at 11:54 AM, Eve Maler wrote:

- BUT... Another way to distinguish the relationships would be temporal. Is it useful to split some of the actors into "untrusted" and "trusted" phases? For example, the requester/requesting party spends a considerable amount of time interacting with other UMA parties before it's actually given any access authorizations, and (say) the AM should be liable for such authorizations yet. Should we treat this as a whole other "actor"? (I don't think any other parties deserve this distinctive treatment, but could be convinced otherwise.)

It should say "the AM shouldn't be liable..."

[j stollman]

1. - Does it make sense to distinguish the different things being relied on in separate TRs for the same pair of actors, or should they be considered as multiple elements of the single trust relationship between them?  E.g., TR-3 and TR-4 both refer to some aspect of trust between the host and requester. Is it better to combine them, since all trust between them gets forged through the exact same process?

I believe that we need to articulate the TRs at the most granular level because it may require different solutions to address the different variations.  We don't actually trust another party.  We trust another party to act a certain way.  Trusting one a party to perform one action does not imply universal trust of that party to perform all actions.  E.g., even within the same form of trust, we may be willing to trust screwyu.com to deliver our ordered merchandise for a small purchase, but not trust them for a larger transaction.

2. Re:  creating a constellation for each and every user story.

While for the subset of transactions that UMA will support, you may well be able to get by with a limited articulation of the trust model.  But, ultimately, I think it is vital to articulate the full model in order to align all of the various identity/privacy/security/notice efforts to the same set of requirements.  This will allow us to specify not only the system-of-systems requirements that apply to each subset, but it will also allow us to clearly scope the boundaries of these various subsets to keep them from either solving the same problem different ways or leaving a critical gap that falls between the cracks.

My personal view of the trust framework is that:

There is only one Trust Framework.  It is the web of trust necessary for a full range of transactions to occur.  It already exists in that we know (even though we have yet to articulate) all of the considerations that we need addressed in order to trust all of the counterparties in a transaction.  The counterparties include not only an IdP and an RP, but also the network providers, federation operators, assessors and auditors, etc. 

Our current mission is to articulate the Trust Framework in order to document the "real" requirements which are those policies, tools, processes, and legal structures (potentially a subset of processes) necessary to create trust among all of the parties.   Think of the Trust Framework as a skeleton of an ancient dinosaur.  The species has only a single structure, but since all members of the species are long dead, we have never actually seen one to know what the structure is.  We are like paleontologists unearthing bone fragments and trying to piece together what the whole thing looks like. 

Our problem is that various groups among us are digging in different places (using different use cases) and unearthing different fragments – only some of which are common to those found by other groups. 

Each group is imagining a different structure to the creature based on their limited sampling of bone fragments.  One group believes it flies, another that it crawls or walks, and yet another that it swims.  One group believes it is a carnivore; another an herbivore.  Their conclusions are all consistent with their subset of the evidence that each has unearthed.  But because they haven't combined their knowledge, each has too small a portal to imagine the fully articulated skeleton.

Until we can amalgamate all of our fragments, it is unlikely that we will be able to create the correct model.  And by failing to acknowledge all of the other pieces of the puzzle, we are creating science that is likely not only to lead us astray (e.g., create poor and conflicting regulations), but also cause each group to dig in its heels to defend their current model.  This will forestall our ability to “get it right.”

Jeff

_______________________________________________
WG-UMA mailing list
WG-...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma

--
Jeff Stollman
stoll...@gmail.com
1 202.683.8699

[Eve Maler]

Jeff, thanks for weighing in! More thoughts below.

On 13 Feb 2011, at 3:09 PM, j stollman wrote:

1. - Does it make sense to distinguish the different things being relied on in separate TRs for the same pair of actors, or should they be considered as multiple elements of the single trust relationship between them?  E.g., TR-3 and TR-4 both refer to some aspect of trust between the host and requester. Is it better to combine them, since all trust between them gets forged through the exact same process?

I believe that we need to articulate the TRs at the most granular level because it may require different solutions to address the different variations.  We don't actually trust another party.  We trust another party to act a certain way.  Trusting one a party to perform one action does not imply universal trust of that party to perform all actions.  E.g., even within the same form of trust, we may be willing to trust screwyu.com to deliver our ordered merchandise for a small purchase, but not trust them for a larger transaction.

Sure. But individual authorization decisions are what "do with" UMA, rather than "what UMA does"; it only sets up trust relationships that makes authorization decisions possible. And the protocol doesn't have lots of options for fine-grained trust choices when, say, a host and AM meet for the purpose of having the host outsource authorization decisions to the AM; there's a specific bucket of things each one expects the other to do in good faith. There are two ways to articulate all the pre-conditions in the bucket:

TR-1, TR-2, TR-3 etc., all with AM liable and host relying; each lists one thing the host trusts the AM to do

TR-10, TR-11, TR-12, etc., all with host liable and AM relying; each lists one thing the AM trusts the host to do

or

TR-1: AM is liable and host is relying; host trusts the AM to live up to a, b, c, d, etc.

TR-2: host is liable and AM is relying; AM trusts the host to live up to e, f, g, h, etc.

I think you're arguing for the first. I guess I'm wondering exactly what it buys us, since the sub-clauses are inseparable in practice. Also, it seems reasonable to me that you'd talk about their single (unidirectional) "trust relationship", rather than the many relationships between the same pair of parties over and over.

Or am I splitting hairs?

2. Re:  creating a constellation for each and every user story.

While for the subset of transactions that UMA will support, you may well be able to get by with a limited articulation of the trust model.  But, ultimately, I think it is vital to articulate the full model in order to align all of the various identity/privacy/security/notice efforts to the same set of requirements.  This will allow us to specify not only the system-of-systems requirements that apply to each subset, but it will also allow us to clearly scope the boundaries of these various subsets to keep them from either solving the same problem different ways or leaving a critical gap that falls between the cracks.

Hmm, I think we may be talking at cross purposes here. Maybe Rainer can jump in and explain the purpose of constellations as he sees them. I was seeing them as variations on a theme, designed to tease out subtleties of trust in the corners of any one model. That's why it made me think of our person-to-* sharing options, each of which has different goals for liability effects. More below.

My personal view of the trust framework is that:

There is only one Trust Framework.  It is the web of trust necessary for a full range of transactions to occur.  It already exists in that we know (even though we have yet to articulate) all of the considerations that we need addressed in order to trust all of the counterparties in a transaction.  The counterparties include not only an IdP and an RP, but also the network providers, federation operators, assessors and auditors, etc.

We seem to have a tangle of nouns here. :-) Trust model, trust framework, constellation, scenario...

First, let me note that, to me, our current exercise is merely about documenting the trust model for our protocol. Every federated topology (such as a PKI) and every open protocol or API has to have some model for who is outsourcing what to whom -- in essence, the unchanging parts of the protocol contract. All the technologies that support SSO have roughly the same trust model, which is what I think is being built in the Fed Interop group, but the UMA model is unique. Trust models are necessary to understand for membership in a community that is using a trust framework, but insufficient.

Having helped put together the OITF document, I would say I agree it's important to converge on a single trust framework model if we can. But I don't know if it's possible to converge on literally a single trust framework for everyone to use, at least as we defined the term. We designed the OITF model to support multiple trust framework instances for different communities, so that parties could sign on to different levels of responsibility depending on, e.g., the kind of screwyu.com vs. high-value transaction distinction you noted above.

Further, though I tried to soften the assumptions in the OITF document about specific role names such as IdPs and RPs vs. generic asserting/relying actors, in practice everyone's still assuming the classic federated identity triangle of IdP/RP/user in most of the trust framework discussions. UMA doesn't even have a triangle -- it's more like a square. There's no reason an UMA-compliant actor couldn't be part of a trust framework, but the framework is going to have to accommodate UMA entity roles (e.g., assessors for three actors, not two) and point to profiles of the UMA protocol (in the same way SAML, OpenID, and InfoCard are profiled today for the ICAM framework).

As a really specific example of how UMA messes with classic federated identity, look at our tClaims discussions. In them, we have an an IdP that is an UMA host (of trustworthy claims). Thus, the IdP in this case becomes a relying party on an AM for something (authorization decisions) that aren't even at the trust-framework table today.

Now I've really wandered into the philosophical weeds! But I hope this helps.

[Susan Morrow]

I’ve read and re-read your comments trying to assimilate them all but one thing kept jumping into my mind.

 

Rainers work is based on a ternary relationship and the trust model is broken down into 3N-1  i.e. a pairwise model

 

So logically if UMA is a quaternary model and using the same principle, then the trust model should shake out to be 4N-1 , i.e. a ternary model

 

Am I making sense?

 

i.e. instead of pairwise actors you would have a trio of actors all interacting at any given scenario – this of course adds another dimension of complexity into the trust model – going from essentially  x, y  to x,y,z

 

The table would need to reflect this so we could then call on this to tease out each scenario

 

What do you think, am I barking up the wrong tree, or if not, making it to complex for this particular task?

 

I’m on a train for 6 hours tomorrow and I’ll take all your comments and try and pull together another version of the initial attempt I made for us to look at before Thursday

 

Susan

p.s. I still think that privacy and security could be layered into the model as separate considerations and although we may not do that in the first pass we could make reference to this as an extension of the initial model??

[Eve Maler]

Wow, second-order trust relationships!  I still think, though, that relationships-of-two are the most important, since they're the "atoms" from which other relationships are built. In fact, perhaps that is the salient characteristic of a "trust framework": it's the only thing that gets you relationships among n parties out of the box, since there's a hub/broker making it happen. So just because we have four actors doesn't mean we can't leverage the TR formalism in the exact same way as it's being used in the other group.

Eve

So I think the Rainer way of approaching things is still valid, at least as an important starting point

[Susan Morrow]

Fair point and it would complicate things massively without necessarily adding benefit. I had to follow the train of logic though to see what popped up

 

I guess that ultimately every relationship is based on two and the third party is just an extension of that – I suppose a pair wise table, if comprehensive would take any extraneous relationships into account anyway – just in a more 2D way

[j stollman]

In several lengthy sessions during the week in SF, my description of the work that Rainer and I started has changed.  (The work is the same, but the change in spin is important.)

First we have stopped calling what we are doing a Trust Framework.  While that may be an accurate dictionary definition, it is not the same as all of the other framework efforts being undertaken.  Instead, we are using a term suggested by John Bradley:  Trust Framework meta model.

What we are trying to compose in the meta model is a comprehensive set of all of the unidirectional, pairwise trust relationships that exist for transactions.  This is not limited to internet transactions.  We believe that there is a finite group of these that is within the realm of practicality to articulate.

The meta model will then serve several purposes:

1. It will provide a baseline against which other trust frameworks (including subsets such as Identity frameworks and privacy frameworks) can be assessed for comprehensiveness of coverage (gap analysis).
   
2. It will allow various tools an processes to be assessed to ensure that a solution developed to satisfy one (or a set of) trust elements does not violate other trust elements.
3. It will allow decisions on parsing the meta model into component frameworks (e.g., identity, privacy, notification) to avoid overlap and gaps.
   
4. It can be used to define "system-of-systems" requirements to be passed through to such subset frameworks.to ensure that the various subsets properly mate when combined to maintain the integrity of the resulting model.
   

Perhaps this revised "spin" will provide more clarity rather than muddying the waters as I have with my previous comments.

Thank you.

Jeff

On Mon, Feb 14, 2011 at 6:52 AM, Susan Morrow <susan....@avocosecure.com> wrote:

Fair point and it would complicate things massively without necessarily adding benefit. I had to follow the train of logic though to see what popped up

 

I guess that ultimately every relationship is based on two and the third party is just an extension of that – I suppose a pair wise table, if comprehensive would take any extraneous relationships into account anyway – just in a more 2D way

 

From: Eve Maler [mailto:e...@xmlgrrl.com]

Sent: 14 February 2011 14:43
To: Susan Morrow

[Susan Morrow]

Hi Jeff,

 

Thanks for this.

 

I’m meeting with Rainer on Monday so I’m sure he’ll go into the details of how to mimic your meta model so we can apply it to UMA.

 

We discussed similar things on the UMA call last night too with regards to the trust relationships and teasing them out so we have the right ones to work with. It seems to be the pivot upon which the model will stand.

 

Best wishes

 

Susan