[WG-UMA] For trust model geeks, part four
Eve Maler
eve at xmlgrrl.com
Sun Nov 20 20:37:25 EST 2011
(BTW, if I miss anyone's contribution to the thread, please do feel free to forward it along!)
Begin forwarded message:
> From: Kevin Cox <kevin.cox at edentiti.com>
> Subject: Re: Arise, Trust Model geeks!
> Date: 15 November 2011 12:02:21 PM PST
> To: Eve Maler <eve at xmlgrrl.com>
>
> The following are some "random" thoughts about trust.
>
> In our deployment of User Managed Access the individual identity is also the AM. We think of our company as providing the tools for an individual to control their own AM. Making the person responsible for the AM simplifies deployment. It enables user managed access and user managed verification - and can be the foundation for a trust framework.
>
> However, the legal system directs people towards specifications in terms of ownership of the machines on which data resides. This in turn means that we get the idea of trust as being about the trust in the integrity of data. This is important but there is more to trust.
>
> In a cloud environment it is who controls access to the data and controls what data is stored that determines ownership. The legal system will catch up to the technology once there are a few cases to test this idea of ownership as being about access and control rather than physical possession. If we have this model of who controls access then trust is also built on the trust we have in people not just the trust we have in data.
>
> Individuals can trust themselves hence the reason why trust can be built on this premise. If the person is in control of the data and the access to the data then they will trust it. They also have to trust the system that supplies the service.
>
> Organisations can trust the system if the data that they have is controlled by them and the AM only points to that data - not stores it. To give an example. We use government issued physical credentials as the main method of verification. If a person possesses a passport then the AM does not store the data in the passport but stores the fact that there is a passport and has a way of retrieving the passport without using the passport identifier. It stores data that enables the passport information to be retrieved. This is created when the fact that the passport exists is established. This means the passport organisation owns the data so trusts it. The individual owns the pointer to the passport information and so trusts it.
>
> The individual provides the AM with data about themselves that they can use to authenticate themselves to the AM. This data may be a physical thing like a phone number or computer id, a secret like a password, a biometric like a photograph or voice print. As with the verification data the AM does not necessarily store this information but points to it. For example we use OpenID for passwords. This trust that an individual has in this information is established because they establish the link and each time they use the AM the trust is confirmed.
>
> Trust is broken when a person establishes multiple identities with the same organisation. For example a person has two passports. .
>
> Trust is broken when a person allows their identity to be used by someone else. For example a person allows another person below the legal age limit to purchase liquor.
>
> Trust is broken when an organisation allows a record to be created fraudulently - that is a record about an individual is created by someone other than the person themselves.
>
> Trust is broken when another person creates an electronic identity with credentials of someone else. Thus another person uses my passport to create an identity that they then use.
>
> A rule about building trust is that breaches of trust are recorded and future transactions take these breaches into account. Another rule is that successful accesses to data are recorded and the more successful ones are made the greater the trust.
>
> A measure of trust that a person has in a piece of data is who created it and how many times has it been successfully accessed without challenge.
>
> However it appears that trust is related more to the perception of the number of suspected undetected fraudulent transactions rather than the number of successful transactions. Trust is also based on the behaviour of the system when a fraudulent transaction occurs. If people can trust the system to make good any damage from fraudulent transactions then people will continue to use the system.
>
> One of our biggest problems in deploying our systems is in getting the system past the lawyers and the risk and compliance people. What they do is look at legislation to see that rules are being followed. They like prescriptive regulations so they can use check lists to see everything has been covered. This means there is considerable pressure on regulators to write prescriptive rules. The legislators know that prescriptive rules are not good because things - like risk, and trust - cannot always be enumerated but are dynamic as they are social constructs. What happens is the regulators are forced to give examples and those examples tend to become the prescriptions. Australia's anti money laundering laws say that identification is to be risk based. That is, the organisation must identity people according to the risk of the transactions that the person will conduct. This was not enough for industry and the regulators were required to give examples of what would be sufficient to identify a person so that the organisation could not be sued if they got the identification wrong. Those examples have now become prescriptive and organisations now think that is sufficient. Unfortunately the examples are built on the ideas of data integrity not on ideas of trust or of risk.
>
> It would be good if the rules and regulations were built around outcomes rather than how to do things. This may help in building a trust framework. Perhaps it is possible to write a trust framework so that the objectives are to reduce the number of occurrences of violation of trust rather than do this and you will be OK?
>
> Kevin
>
>
> On Tue, Nov 15, 2011 at 2:35 AM, Eve Maler <eve at xmlgrrl.com> wrote:
> This looks very helpful as a way to get potential deployers on board and comfortable. I'd love to see another layer of detail ultimately -- for example, what features of UMA (likely in combination with OpenID Connect) would a deployer want to profile, enhance, or extend to get the trust/risk picture they desire?
>
> Let's use Project hData as an example. Gerry Beuchelt has said that it's likely the AM operators would all be the insurance companies (noting that this is probably US-centric). I've cc'd him to get his further thoughts. How would host and requester operators be provably qualified to approach AMs? How would AMs be trustable? What claims specific to this universe would have to be supported?
>
> Eve
>
> On 13 Nov 2011, at 8:13 AM, Domenico Catalano wrote:
>
> > Hi all,
> >
> > I've tried to explore some ideas and thoughts for the trust model user guide.
> > Attached a briefly presentation, mainly take a look at the slides 3 and 4.
> >
> > what do you think?
> >
> > Dom
> > <UMA_TrustModel_Defv01.pdf>
> >
> > On Nov 7, 2011, at 2:13 AM, Eve Maler wrote:
> >
> >> Belatedly… I can see I've found the right passionate people to carry this through. :-) Just a couple of thoughts:
> >>
> >> #1 We really need your careful review of the existing Trust Model document, to see if it builds the kind of technical-to-contractual-to-legal framework that jilted parties can start to rely on when something goes wrong. Keep in mind that the usual discussions of "identity trust frameworks" focus on IdPs and RPs, not so much AMs, hosts, requesters, requesting parties, etc.
> >>
> >> #2 What Rainer was suggesting we still need, beyond this document. is a kind of "user guide" for UMA deployers, to help them specify the missing pieces that bind UMA plumbing to their contractual choices. This could maybe be presented as a form/survey/questionnaire for each party, possibly accompanied by a template or instructions for an "UMA profile" that would ensconce choices in the technical layer.
> >>
> >> Let me know what you think.
> >>
> >> Eve
> >>
> >> On 30 Oct 2011, at 4:24 PM, Kevin Cox wrote:
> >>
> >>> If you build any trust system you also have the problem of what to do
> >>> with people who cheat or who "break the trust we had in them". The
> >>> general approach is to "un-trust" them and we reduce those occasions
> >>> when they are trusted and/or require them to do extra things in order
> >>> to regain trust.
> >>>
> >>> Again what to do when trust is broken does not seem to appear in most
> >>> trust frameworks. It is assumed that the system will be built so that
> >>> all transactions can be trusted. A more practical trust framework
> >>> would assume that trust is sometimes broken. The framework would
> >>> indicate how broken trust is detected and what to do about those
> >>> agents that prove untrustworthy.
> >>>
> >>> Our approach to detection is to make sure individuals know what has
> >>> been done in their name and to give them ways of challenging those
> >>> actions, and proving it was not them. They should have the ability to
> >>> expunge the actions from their record and if possible move the
> >>> responsibility to someone else. If a person is found to have abused
> >>> trust then they are not permitted to participate in that activity for
> >>> some period of time. This is normally punishment enough.
> >>>
> >>> Kevin
> >>>
> >>> On Mon, Oct 31, 2011 at 4:29 AM, Kevin Cox <kevin.cox at edentiti.com> wrote:
> >>>> In our implementation of an "identity provider" we have found the
> >>>> trust in the representation of identity and trust in the integrity of
> >>>> the system is not a sufficient on which to build a trust framework.
> >>>> That is it is not only the data that is basis for trust. It is also
> >>>> the trust that an individual has that the representation, and its use
> >>>> as a representation of them, that is important. If the representation
> >>>> and its access is trusted by the person it represents then trust
> >>>> follows. If it is not then the edifice crumbles.
> >>>>
> >>>> To give an example. Let us say we have an implementation that
> >>>> includes a "wallet". How do we know if this representation is trusted?
> >>>> We know it is trusted if at the time it is accessed the individual
> >>>> trusted it and agreed to the access. This is what UMA is all about but
> >>>> it is also what is required if there are legal issues around the use
> >>>> of an identity representation. What is it that a judge will require
> >>>> when determining who was responsible for an electronic action? First
> >>>> was the action taken by an electronic agent representing the person
> >>>> and second did the individual authorise the action. The first part is
> >>>> the data part and is handled by encryption and trust in the integrity
> >>>> of data stores. The second part is the trust we have in the system
> >>>> (agent) that performed the action. It is this part that UMA addresses.
> >>>> A judge will determine this based on whether the user knowingly gave
> >>>> permission and this is where the details of the interaction of the
> >>>> individual with the system becomes important. Obviously we cannot
> >>>> have a trust framework built on details of interactions. But we can
> >>>> generalise it to be if is reasonable to assume the individual trusted
> >>>> the permission to gain access then it is reasonable for the individual
> >>>> to take responsibility for the action, (This all assumes there is
> >>>> trust in the integrity of the data stores and systems that hosted the
> >>>> representation of the individual.)
> >>>>
> >>>> Unfortunately I do not have a good bibliography to supply but in most
> >>>> of what I have read the trust in data stores and trust in systems is
> >>>> well covered. What seems to be missing in trust framework discussions
> >>>> is - was it reasonable for an individual to know the consequences of
> >>>> the actions the system took on their behalf.
> >>>>
> >>>> Kevin
> >>>>
> >>>>
> >>>> On Sun, Oct 30, 2011 at 8:10 PM, Susan Morrow
> >>>> <susan.morrow at avocosecure.com> wrote:
> >>>>> HI Eve,
> >>>>> Do you mean a bit like the open identity trust framework document (weren't
> >>>>> you involved in that?) where it outlines the various aspects that make up
> >>>>> the framework of the model?
> >>>>> Maybe though we could also introduce our philosophy of thought around the
> >>>>> merging of technology, policy and legal standpoints? (BTW that particular
> >>>>> point, I feel, is one that is a turning point in the industry as a whole,
> >>>>> I.e. The convergence of previously separated approaches).
> >>>>> To this end, a guidance document which incorporates in its introduction, the
> >>>>> philosophy behind the approach, should be integral. We can then get to the
> >>>>> specifics of approach and talk about the pairwise relationships and
> >>>>> importantly Dominico's work too.
> >>>>> Susan
> >>>>> From: Eve Maler <eve at xmlgrrl.com>
> >>>>> Date: Sat, 29 Oct 2011 14:26:12 -0700
> >>>>> To: "frankwray at cfl.rr.com Wray" <frankwray at cfl.rr.com>, Salvatore D'Agostino
> >>>>> <sal at idmachines.com>, Susan Morrow <susan.morrow at avocosecure.com>, Kevin Cox
> >>>>> <kevin.cox at edentiti.com>, Domenico Catalano <domenico.catalano at oracle.com>
> >>>>> Subject: Re: Arise, Trust Model geeks!
> >>>>>
> >>>>> Oh, I also wanted to point you to this site, which Dazza Greenwood mentioned
> >>>>> to me at IIW:
> >>>>> http://idcubed.org/
> >>>>> (Yes, once again, cubes. :-) )
> >>>>> Eve
> >>>>> On 28 Oct 2011, at 6:52 PM, Eve Maler wrote:
> >>>>>
> >>>>> The WG agreed on Thursday that we should start up a Trust Model
> >>>>> best-practices/guidance document, since the current Trust Model document is
> >>>>> more like a technical spec than a true helper for someone who wants to use
> >>>>> UMA with trust frameworks, or in a legally enforceable way.
> >>>>> Below is some food for thought. What would the structure of an actual
> >>>>> instruction manual for specifying "trust-enabled" UMA usage look like? Can
> >>>>> we bat around an outline, requirements, snippets of text., etc. and
> >>>>> eventually turn it into a wiki page?
> >>>>> Thanks for your thoughts! Let's plan to report back on our progress on
> >>>>> Thursday.
> >>>>> Eve
> >>>>> http://kantarainitiative.org/confluence/display/uma/UMA+FAQ
> >>>>> What is required to make an UMA deployment model "legal" from a privacy,
> >>>>> consent, and agency standpoint?
> >>>>>
> >>>>> The embedding of user-dictated policy in UMA makes it an explicit "carrier"
> >>>>> for user permission, even if consent is not gathered in real time. Taking
> >>>>> into account implementation and UX choices, trust model considerations, and
> >>>>> various strengths of "assurance" in any one deployed system, further
> >>>>> profiling of UMA may be warranted to reduce unwanted variability.
> >>>>>
> >>>>> For example, the core UMA spec leverages OAuth for the authorizing user's
> >>>>> introduction of the host to the AM. The core spec allows for both explicit
> >>>>> (authorization coe) and implicit (SAML assertion) forms of user consent for
> >>>>> this connection. Profiling may be warranted to require only explicit
> >>>>> methods, and even to dictate user experiences for consent and authorization.
> >>>>>
> >>>>> As well, wherever various outside-of-UMA terms of service or strong
> >>>>> authentication needs might come into play, such as in the authorizing user's
> >>>>> mutual agreements forged with AM or host sites, or the strength of
> >>>>> "assurance" about a requesting party's claims, profiling may be warranted to
> >>>>> require certain terms of service or authentication or verification
> >>>>> strengths, or alternatively membership in various trust frameworks that will
> >>>>> dictate such answers.
> >>>>>
> >>>>> Finally, where interoperability within an ecosystem will demand that certain
> >>>>> types of policies about certain claim types must be available, it may be
> >>>>> wise to define a mandatory-to-support set of claims and claim assurance
> >>>>> strengths.
> >>>>>
> >>>>> Further reading:
> >>>>>
> >>>>> UMA Trust Model
> >>>>> W3C workshop position paper on Controlling Data Usage with UMA
> >>>>>
> >>>>>
> >>>>> Eve Maler http://www.xmlgrrl.com/blog
> >>>>> +1 425 345 6756 http://www.twitter.com/xmlgrrl
> >>>>>
> >>>>>
> >>>>>
> >>>>> Eve Maler http://www.xmlgrrl.com/blog
> >>>>> +1 425 345 6756 http://www.twitter.com/xmlgrrl
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> 0413961090
> >>>> Home +61 2 62410647
> >>>> Skype cscoxk or +61 2 61003884
> >>>> Fax +61 2 6103 0144
> >>>>
> >>>> http://www.linkedin.com/in/kevinrosscox
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> 0413961090
> >>> Home +61 2 62410647
> >>> Skype cscoxk or +61 2 61003884
> >>> Fax +61 2 6103 0144
> >>>
> >>> http://www.linkedin.com/in/kevinrosscox
> >>>
> >>
> >>
> >> Eve Maler http://www.xmlgrrl.com/blog
> >> +1 425 345 6756 http://www.twitter.com/xmlgrrl
> >>
> >
>
>
> Eve Maler http://www.xmlgrrl.com/blog
> +1 425 345 6756 http://www.twitter.com/xmlgrrl
>
>
>
>
> --
> 0413961090
> Home +61 2 62410647
> Skype cscoxk or +61 2 61003884
> Fax +61 2 6103 0144
>
> http://www.linkedin.com/in/kevinrosscox
>
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/20111120/4f21c81e/attachment-0001.html
More information about the WG-UMA
mailing list