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

Mark Lizar mark at smartspecies.com
Tue Jul 6 10:29:37 EDT 2010


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.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20100706/289edc86/attachment-0001.html 

More information about the WG-UMA mailing list