[WG-UMA] For trust model geeks, part five (the last)

Eve Maler eve at xmlgrrl.com
Sun Nov 20 20:38:02 EST 2011

Begin forwarded message:

> From: Domenico Catalano <domenico.catalano at oracle.com>
> Subject: Re: Arise, Trust Model geeks!
> Date: 20 November 2011 2:41:27 PM PST
> To: Susan Morrow Avoco Secure <susan.morrow at avocosecure.com>
> Cc: Eve Maler <eve at xmlgrrl.com>, Kevin Cox <kevin.cox at edentiti.com>, "frankwray at cfl.rr.com" <frankwray at cfl.rr.com>, "SalvatoreD'Agostino" <sal at idmachines.com>, GeraldBeuchelt <beuchelt at mitre.org>
> Hi all,
> Here is last thoughts about hdata UMA trust model profile.
> Attached a sketch. I hope it is useful for exploring the UMA trust framework.
> Sent from my iPad
> On Nov 17, 2011, at 5:04 PM, Susan Morrow Avoco Secure <susan.morrow at avocosecure.com> wrote:
>> Hello,
>> Sorry for such a delay in replying to this thread but I am snowed under with herding crazy cats (also known as business analysts, implementation and software design specialists)
>> My take on documenting the Trust Model for discussion later (and forgive me if im out of sync with things):
>> The user guide could be broken down into the following chapters and sub chapters as an introduction to the core content of the current trust relationship wok (qualitative) and Dom's Elemental work (quantitative) 
>> 1. Introduction to Approach - An explanation of the qualitative and quantitate approaches to describing the TR's in the UMA model
>> 1a. Trust Relationships - a look at the UMA model constellation breakdown and how each R has been formed
>> 1b. The elements of trust  -an overview of how a quantitative view of the UMA TR's can add a deeper understanding of the level of trustworthiness within any given sub-system
>> 1c. Other angles (maybe threat profiles as previously mentioned could be introduced here
>> 2. Implementation Considerations - a look at how trustworthiness can be increased (examples could be Use of certificates for signing and use of claims based ID systems such as OPenID)
>> Anyway - food for thought during today's call?
>> Sus
>> -----Original Message-----
>> From: Domenico Catalano [mailto:domenico.catalano at oracle.com] 
>> Sent: 15 November 2011 22:30
>> To: Eve Maler
>> Cc: Kevin Cox; Susan Morrow; frankwray at cfl.rr.com Wray; Salvatore D'Agostino; GeraldBeuchelt
>> Subject: Re: Arise, Trust Model geeks!
>> I think we need qualifier better what are the threats model for this specific scenario. For instance, if the AM would be the assurance company, the AM could access (unauthorized access) to hdata at Host to know about patient health, in order to obtain useful information and modify patient assurance policy or reject any new contract. Is this a threat scenario?
>> Dom
>> Sent from my iPad
>> On Nov 14, 2011, at 4:35 PM, 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

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/8d815ab1/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 1240007 bytes
Desc: not available
Url : http://kantarainitiative.org/pipermail/wg-uma/attachments/20111120/8d815ab1/attachment-0001.png 

More information about the WG-UMA mailing list