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

Eve Maler eve at xmlgrrl.com
Fri Jul 2 11:50:52 EDT 2010


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20100702/550df62e/attachment-0001.html 


More information about the WG-UMA mailing list