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

Mark Lizar mark at smartspecies.com
Mon Jul 12 12:50:56 EDT 2010


FYI - Conference calling details for the UMA Legal Call .


>
>
> Attendee Teleconference Info:
> - Skype: +9900827042954214
> - North American Dial-In: +1-201-793-9022
> - Room Code: 2954214
>
> Cheers,
> Dervla
> ________________________
> Dervla O’Reilly
> Program Manager
> Kantara Initiative
> +1 415 731 4487 business
> +1 415 948 3650 mobile
> +1 509 757 4487 fax
> dervla[at]kantarainitiative[dot]org
> http://www.kantarainitiative.org
>
> On Jul 12, 2010, at 9:38 AM, Mark Lizar wrote:
>
>> Hi
>>
>> There is a Sub-WG call in 20 minutes without a moderator.  Is it  
>> possible to get the details for this?
>>
>> - M
>>
>> Begin forwarded message:
>>
>>> From: Mark Lizar <mark at smartspecies.com>
>>> Date: 10 July 2010 13:21:29 BST
>>> To: Eve Maler <eve at xmlgrrl.com>, WG UMA <wg-uma at kantarainitiative.org 
>>> >
>>> Subject: Re: [WG-UMA] Fwd: IIW Topic: UMA and the Law: Call Schedule
>>>
>>> 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
>>> _______________________________________________
>>> 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/20100712/3ba390e3/attachment-0001.html 


More information about the WG-UMA mailing list