[WG-UMA] Fwd: IIW Topic: UMA and the Law

Mark Lizar mark at smartspecies.com
Mon Jul 5 08:06:17 EDT 2010

I am really interested in what goes with the 'auditing regiems'  that  
is possible with UMA.  Legally it is interesting to explore the uses  
of UMA to enable an individual to control their own information and  
negotiate use of shared information in the future.

So far in the two UMA legal calls we looked at the legal aspects and  
impacts of contracts that may be involved.

Issues raised for next Agenda from last Call
- Enforcement
- Automation levels and the need for user/ host/AM/requester action
- Terms of Service Negotiation
- Unique User Imposed Conditions (advanced UMA)
- Liability
- Policy Recommendations for the use of UMA.  (where the law may be  
lacking and UMA can 'bridge a gap;)

I would like to discuss this last item of Policy Recommendations in  
more depth and discuss what the potential of UMA legally is, and the  
impact 'user managed access' can have on today's policy  
infrastructure.  The idea of resident user policy (like a standard  
agreement) I think may be quite a powerful tool legally and I wonder  
if a UMA and a standard agreement can compete or interact with  
existing privacy policy and terms of service infrastructure.

I know that there is a Meeting set-up for tomorrow, although I am  
unsure who can attend. So  I have just set-up a new doodle poll to see  
who can attend tomorrow, and also a couple of alternatives to  
tomorrow. (just in case) I would like to chat further about this in  
the next call.  I know we have a call arranged for tomorrow but I am  
not sure of who is attending and it would be good to organise a call,  
based on the above agenda, that everyone interested can attend.   If  
there are aspects of the above agenda that we can discuss on the list,  
it would be good to do this as well.

Here is an open invite and a link to the Doodle poll to schedule a  
time when we are all able to meet. Please check fill in this doodle  
poll right away (to show your interest) for tomorrow's call.  Also, if  
you have yet to agree to the Group Participation Agreement, please  
follow this link here  to agree prior to attending a call.



On 2 Jul 2010, at 17:45, Eve Maler wrote:

> In practice, I'd say, having globally recognizable and certifiable  
> assurance levels/quality means having a trust framework of the OIX  
> or IAF sort. The NIST spec just makes requirements for identity  
> assurance at four levels (other similar standards exist), and other  
> stuff on top has to say how to certify at that level for various  
> purposes. There are opportunities for baking much more "semantics"  
> into it than just a bare assurance level number, but it all depends  
> on how successfully a trust framework rolls up those semantics and  
> turns them into contracts, auditing regimes, certified-entity lists,  
> etc...
> 	Eve
> On 2 Jul 2010, at 9:26 AM, Joe Andrieu wrote:
>> "Bob at gmail.com can get access to this if I'm assured, to NIST:LOA2,  
>> that it's him".
>> Does the LOA2 specification address the question of whether or not  
>> an entity other than the owner of gmail.com is capable of assuring  
>> that identity? Or do we need to clarify the range of identity  
>> providers that are acceptable for assurance, perhaps through a  
>> whitelist or trust framework?
>> In part that is a question of whether or not the identity must be  
>> parsed to extract the identity provider, and if so, what are the  
>> rules for valid identifiers?  If not, how do we find a suitable IDP  
>> for a given identifier? Or are these questions inherently answered  
>> in the NIST LOA spec for each level (my guess is that the LOAs  
>> don't address this)?
>> -j
>> Joe Andrieu
>> joe at switchbook.com
>> +1 (805) 705-8651
>> http://www.switchbook.com
>> On 7/2/2010 8:50 AM, Eve Maler wrote:
>>> Trying to re-awaken this thread... To summarize (hoping others  
>>> will correct me as necessary), Bob P. was positing that part of  
>>> the policy requirement governing access might be around the  
>>> assurance level of a requesting party's identity.  If we can make  
>>> some (big-leap) assumptions that assurance levels are well enough  
>>> standardized on a global level and that UMA-protected claims  
>>> (Domenico's trust model) can deliver up identity claims that  
>>> accurately carry a level of assurance, we may be able to allow  
>>> Alice to set authorization policies like this: "Bob at gmail.com can  
>>> get access to this if I'm assured, to NIST:LOA2, that it's him".  
>>> Domenico's proposal about the requesting party having to approve  
>>> release in real time gives us a place for that party to *log in*  
>>> and consent, which gives a place to capture a fresh authentication  
>>> assertion.
>>> Other thoughts?
>>>  Eve
>>> On 28 May 2010, at 12:31 PM, Eve Maler wrote:
>>>> Bob and Jeff gave me the go-ahead to forward the thread below, so  
>>>> that others could benefit and participate...
>>>> Begin forwarded message:
>>>>> From: Bob Pinheiro <kantara at bobpinheiro.com>
>>>>> Date: 28 May 2010 7:21:53 AM PDT
>>>>> To: j stollman <stollman.j at gmail.com>
>>>>> Cc: Eve Maler <eve at xmlgrrl.com>, "Maler, Eve" <Eve.Maler at paypal.com 
>>>>> >, Iain Henderson <iain.henderson at mydex.org>, "mark at smartspecies.com 
>>>>> " <mark at smartspecies.com>
>>>>> Subject: Re: IIW Topic: UMA and the Law
>>>>> Well, as I understand the UMA protocol, the requester *does*  
>>>>> know where to find the AM.  According to the protocol, the steps  
>>>>> are:
>>>>> Requester attempts to access resource at host and is given AM's  
>>>>> requester_token_uri endpoint
>>>>> Requester visits this endpoint, providing its desired scope of  
>>>>> access
>>>>> AM either provides access token, rejects authorization, or asks  
>>>>> requester for claims
>>>>> Requester provides claims as requested, until access token  
>>>>> request either succeeds or fails definitively
>>>>> Bob
>>>>> On 5/28/2010 7:10 AM, j stollman wrote:
>>>>>> Bob,
>>>>>> Consider the possibility that you might choose one AM to define  
>>>>>> policies for multiple information stores on multiple hosts.   
>>>>>> Some of these information stores may include highly sensitive  
>>>>>> information, while others would contain information of low  
>>>>>> sensitivity.
>>>>>> Next consider that the requester interfaces with the user and  
>>>>>> the host and need not know the identity of the AM.  Because the  
>>>>>> requester does not know the identity of the AM, it would be  
>>>>>> difficult for him to find the AM, take advantage of its low  
>>>>>> requirements for authentication to 'break in", and change  
>>>>>> policy settings for information he is seeking from a particular  
>>>>>> host(s) in order to gain access to information that he would  
>>>>>> otherwise be denied.
>>>>>> Unless I am missing something in the UMA model, this would  
>>>>>> suggest these two points would suggest that the authorization  
>>>>>> levels of host and AM need not be the same.
>>>>>> Jeff
>>>>>> On Thu, May 27, 2010 at 5:50 PM, Bob Pinheiro <kantara at bobpinheiro.com 
>>>>>> > wrote:
>>>>>> Eve,
>>>>>> I think I was trying to make the point that someone using a  
>>>>>> personal information store to maintain and possibly distribute  
>>>>>> sensitive personal information may want to protect access to  
>>>>>> that information with something stronger than just a username  
>>>>>> and password.  If that's the case, and a user of a personal  
>>>>>> information store also uses an authorization manager to allow  
>>>>>> requesters to have access to parts of that information, then  
>>>>>> the level of assurance/authentication strength needed to  
>>>>>> establish and modify those access policies should be the same  
>>>>>> as that used for direct access to the information store.  So  
>>>>>> rather than the host demanding that a user authenticate to it  
>>>>>> with the same strength that the user uses at the AM, maybe it  
>>>>>> should be the other way around....the AM should require  
>>>>>> authentication to it with same strength as is used at the  
>>>>>> host.  I'm assuming that here that the user would first setup  
>>>>>> the personal information store, then go to the AM to define  
>>>>>> access policies.  It doesn't seem to make sense that someone  
>>>>>> would go to an AM first without there being some information  
>>>>>> store already there for which access policies needed to be  
>>>>>> defined.  So.....setup information store first, including  
>>>>>> authentiction method, then go to AM to define access policies,  
>>>>>> and AM checks to determine what authentication strength is used  
>>>>>> at the information store.
>>>>>> Anyway, hope that makes sense.
>>>>>> Bob
>>>>>> On 5/25/2010 12:05 AM, Eve Maler wrote:
>>>>>> Hi Bob,
>>>>>> Thanks for the thoughtful message!  A few thoughts back, below.
>>>>>> On 24 May 2010, at 10:25 AM, Bob Pinheiro wrote:
>>>>>> I didn't attend IIW, but I did notice some online notes posted  
>>>>>> on this
>>>>>> topic of UMA and the law.  One point brought up in the notes is  
>>>>>> "What
>>>>>> would incentive hosts to accept an authorization manager's policy
>>>>>> decisions, and all the liability implications thereof?"
>>>>>> Although I haven't been following the UMA and Information  
>>>>>> Sharing work
>>>>>> closely, I assume that the "host" is the place where the user's  
>>>>>> personal
>>>>>> information store, or other protected resource, resides.   
>>>>>> Presumably
>>>>>> Yep, that's correct.
>>>>>> also the act of creating and managing a personal information  
>>>>>> store on
>>>>>> some host is independent of any prior or future relationship  
>>>>>> the user
>>>>>> may have with an authorization manager.   So let's say the user  
>>>>>> creates
>>>>>> a personal information store, and wants to protect access to it  
>>>>>> using
>>>>>> some type of Assurance Level 3 credential.  [Presumably the  
>>>>>> personal
>>>>>> information store may contain sensitive or otherwise valuable
>>>>>> information, and the user may want to protect access to it using
>>>>>> something stronger than just a password].  Assume the user is  
>>>>>> able to
>>>>>> use an OpenID backed by a browser certificate or OTP token, or  
>>>>>> perhaps a
>>>>>> managed Information Card that provides level 3 assurance.
>>>>>> The way UMA currently works, if the user wants to limit access  
>>>>>> to that resource to particular identities with particular  
>>>>>> strengths of assurance, the user would craft policies at the  
>>>>>> authorization manager that say so.  (This assumes the AM offers  
>>>>>> this kind of policy as part of its service.)  And any requester  
>>>>>> approaching the host to get access would then have to satisfy  
>>>>>> the policies appropriately.  So far, so good...
>>>>>> Since the UMA protocol requires that the host get an access  
>>>>>> token from
>>>>>> the authorization manager representing the user's consent to  
>>>>>> provide
>>>>>> access to the user's information according to the policies set  
>>>>>> by the
>>>>>> Despite claiming that you're not following closely, this is an  
>>>>>> extremely nuanced observation. :-)
>>>>>> user, it would seem that the level of assurance required for user
>>>>>> authentication to the personal information store should be the  
>>>>>> same
>>>>>> (AL-3) as that required for access to the authorization manager  
>>>>>> for
>>>>>> purposes of setting or changing policy.  A mismatch (such as  
>>>>>> AL-2 for
>>>>>> authentication to the authorization manager, while the personal
>>>>>> information store requires AL-3) would seem to increase the  
>>>>>> host's risk
>>>>>> of providing unauthorized access by a requesting party, and  
>>>>>> hence its
>>>>>> potential liability.
>>>>>> So you're saying that the *host itself* might demand that the  
>>>>>> user authenticate to it with the same strength that the user  
>>>>>> uses over at the AM?  Interesting.  There are all kinds of  
>>>>>> practical problems here having to do with comparing  
>>>>>> authentication strengths (if assurance levels aren't used), and  
>>>>>> even if they are used, they're very likely not the right tool  
>>>>>> for the job.  See this blog post for thoughts on why M04-04  
>>>>>> isn't the right set of use cases to apply to non-gov work:
>>>>>> http://www.xmlgrrl.com/blog/2009/12/31/how-to-rest-assured/
>>>>>> However, what's not clear is whether setting up (and subsequently
>>>>>> accessing) a personal information store, or using the services  
>>>>>> of an
>>>>>> authorization manager, should require that the user's true  
>>>>>> identity be
>>>>>> known, as would be required when obtaining a level 3  
>>>>>> credential.  So for
>>>>>> instance, couldn't I just create a personal information store
>>>>>> anonymously, and use an authorization manager to manage access  
>>>>>> to that
>>>>>> information, provided that the method of authentication to both  
>>>>>> ensures
>>>>>> (with the same degree of confidence) that the authorized user  
>>>>>> who "owns"
>>>>>> the personal information store is the same one who is managing  
>>>>>> access to
>>>>>> it via the authorization manager?
>>>>>> Yes, I think so.
>>>>>> The purpose of UMA is to govern access by others (other people,  
>>>>>> other services on their own behalf, or other services on the  
>>>>>> authorizing user's own behalf) as delegated by the authorizing  
>>>>>> user.  I think you're talking about the last case of the three,  
>>>>>> and certainly -- as we can see in OAuth today -- the user can  
>>>>>> be entirely pseudonymous at the entire set of sites, and even  
>>>>>> use different pseudonyms at each.  (The requester access token  
>>>>>> functions as a very lightweight pairwise host/requester  
>>>>>> pseudonym, along with representing the authorizing user's grant  
>>>>>> of access.  And of course the host access token gotten in step  
>>>>>> 1 functions as an AM/host pseudonym.)
>>>>>> For example, in that third use case, Alice has a login at her  
>>>>>> AM, a login at the host, and a login at the requester service.
>>>>>> (Keep in mind that the requester may have to supply "claims"  
>>>>>> that have nothing to do with a unique identity. I suppose the  
>>>>>> host could object, independently of Alice's policy wishes, if  
>>>>>> some claim supplied by the requester service is at a lower  
>>>>>> "assurance" or quality than the means Alice uses to log in at  
>>>>>> the host, but this hasn't come up to date.)
>>>>>> Assuming that true identities aren't necessarily required, this  
>>>>>> points
>>>>>> to a gap in the current assurance level scheme described in  
>>>>>> OMB04-04.
>>>>>> In other words, what's needed are strong authentication methods  
>>>>>> that are
>>>>>> not necessarily tied to someone's actual identity.  This would  
>>>>>> enable a
>>>>>> self-issued Information Card (which currently would have to be
>>>>>> considered at AL-1 since its identity claims are self-asserted)  
>>>>>> to be
>>>>>> used as a high-assurance authentication credential for UMA and  
>>>>>> personal
>>>>>> information stores, since it provides stronger cryptographic  
>>>>>> functions
>>>>>> but without the identity proofing.
>>>>>> We're definitely singing the same tune on this!  My blog post  
>>>>>> linked above tells the tale...  And Paul Madsen followed up  
>>>>>> with this one:
>>>>>> http://connectid.blogspot.com/2010/01/taxonomy-of-federated-applications.html
>>>>>> BTW, UMA has a design principle (DP9) about protecting the  
>>>>>> privacy of the authorizing user:
>>>>>> http://kantarainitiative.org/confluence/display/uma/UMA+Requirements
>>>>>> As may be necessary from time to time (actually, constantly :-)  
>>>>>> in most access control systems, Alice may need to craft  
>>>>>> policies around access that mention *specific* identities that  
>>>>>> are allowed to gain access, which unmasks at least those  
>>>>>> identities, though they may themselves be pseudonyms;"bob at gmail.com 
>>>>>> "  is a favorite example we use.  We have imagined scenarios  
>>>>>> for both self-asserted identities and third-party-asserted  
>>>>>> ones, but not for any finer gradations.  Our claims system  
>>>>>> could *theoretically* handle any LOA requirements -- but as I  
>>>>>> say, this is the first time it's come up.  Interesting indeed!
>>>>>> FWIW,
>>>>>>        Eve
>>>>>> Bob
>>>> Eve Maler
>>>> eve at xmlgrrl.com
>>>> http://www.xmlgrrl.com/blog
>>>> _______________________________________________
>>>> WG-UMA mailing list
>>>> WG-UMA at kantarainitiative.org
>>>> http://kantarainitiative.org/mailman/listinfo/wg-uma
>>> Eve Maler
>>> eve at xmlgrrl.com
>>> http://www.xmlgrrl.com/blog
>>> _______________________________________________
>>> WG-UMA mailing list
>>> WG-UMA at kantarainitiative.org
>>> http://kantarainitiative.org/mailman/listinfo/wg-uma
> Eve Maler
> eve at xmlgrrl.com
> http://www.xmlgrrl.com/blog
> _______________________________________________
> WG-UMA mailing list
> WG-UMA at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20100705/3d7c6dd1/attachment-0001.html 

More information about the WG-UMA mailing list