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

Mark Lizar mark at smartspecies.com
Sat Jul 10 08:21:29 EDT 2010


Hello All,

The UMA legal call Doodle Poll results are in.

As a result the UMA WG call will take place 1 hour earlier at  
18:00-19:00 BST (UTC/GMT 0), or 10:00 -11:00 PDT (UTC/GMT -8 hours).   
on Monday 12th of July.,

Joni/Eve can you please confirm the conference bridge and call details.



>
> Ok.
>
> I now have all the information. ( It gets a bit more confusing after  
> numerous holidays)
>
> So there is no more confusion, this meeting is scheduled for Next  
> Monday 12th of July 7 PM UTC.  This means that there is no meeting  
> today.  I have updated the Doodle Poll to reflect this day.
>
> So once and for all, there is a UMA legal call, next Tuesday.   
> Please use this Doodle Poll (if you are not able to make this time,  
> and we can arrange accordingly)  http://www.doodle.com/ubhterrb3sq9s36x 
>   to confirm your availability for this call or select and  
> alternative time.
>
> Mark
>
> On 5 Jul 2010, at 13:06, Mark Lizar wrote:
>
>>
>> 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.
>>
>> Thanks,
>>
>> Mark
>>
>> 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
>>
>
> _______________________________________________
> 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/20100710/283f4e0b/attachment-0001.html 


More information about the WG-UMA mailing list