- WG-UMA - mailman.kantarainitiative.org

Fwd: [Cups-friends] SOUPS 2016 Call for Papers, Posters, and Proposals
by Eve Maler 24 Jan '16

24 Jan '16

Anyone interested?? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl [image: SOUPS 2016 banner] <http://s.usenix.org/acton/ct/2452/s-0176-1601/Bct/l-sf-cl-70116000000FReXAA…> SOUPS 2016 is just around the corner with our first deadlines only two weeks away. We are pleased to announce that the Call for Papers <http://s.usenix.org/acton/ct/2452/s-0176-1601/Bct/l-sf-cl-70116000000FReXAA…> and the Call for Posters and Proposals <http://s.usenix.org/acton/ct/2452/s-0176-1601/Bct/l-sf-cl-70116000000FReXAA…> for the Twelfth Symposium on Usable Privacy and Security (SOUPS 2016) <http://s.usenix.org/acton/ct/2452/s-0176-1601/Bct/l-sf-cl-70116000000FReXAA…> are now available. SOUPS 2016 will bring together an interdisciplinary group of researchers and practitioners in human computer interaction, security, and privacy. The program will feature technical papers, a poster session, workshops and tutorials, panels and invited talks, and lightning talks. Please see the Call <http://s.usenix.org/acton/ct/2452/s-0176-1601/Bct/l-sf-cl-70116000000FReXAA…>for Papers <http://s.usenix.org/acton/ct/2452/s-0176-1601/Bct/l-sf-cl-70116000000FReXAA…> and/or the Call for Posters and Proposals <http://s.usenix.org/acton/ct/2452/s-0176-1601/Bct/l-sf-cl-70116000000FReXAA…> for details. Some important dates to keep in mind: *Friday, January 29, 2016*: Proposals for Workshops, Tutorials, Invited Talks, and Panels due *Tuesday, March 1, 2016*: Paper registration deadline *Monday, May 16, 2016*: Poster abstracts and proposals for Lightning Talks and Demos due SOUPS 2016 will be co-located with the 2016 USENIX Annual Technical Conference <http://s.usenix.org/acton/ct/2452/s-0176-1601/Bct/l-sf-cl-70116000000FReXAA…> and will take place June 22–24, 2016, in Denver, CO. Sunny Consolvo, *Google* Matthew Smith, *University of Bonn* soups16chairs(a)usenix.org Please use soups16chairs(a)usenix.org to contact Sunny Consolvo or Matthew Smith. For more details and announcements like and follow our Facebook page at: https://www.facebook.com/SOUPSconference

3 2

UMA for Healthcare - calling all umanitarians
by Adrian Gropper 24 Jan '16

24 Jan '16

UMA is perfect for healthcare. Preamble: Healthcare has just discovered REST and OAuth and is struggling with major unsolved patient identity and privacy problems that UMA can solve. The UMA opportunity is global. Three kinds of health records access have been tried in the developed world (UK has a centralized government-controlled system, AU has a centralized patient-controlled system, and US has a mess of private silos and state exchanges with little or no patient control). It can be argued that all three of these approaches is failing for privacy and scalability reasons. History: For over a year, I've been working with a geek physician (Michael Chen) that has an open-source electronic patient record (EHR) to convert it into an UMA-based and compatible alternative to the three incumbent models above. The idea is to have each patient own and control the technology that hosts their individual health record and use UMA and OIDC to connect her personal EHR server to institutional systems, licensed clinicians, and family caregivers. Michael has made a lot of progress is separating his EHR code into a practice copy and a patient copy and integrating MITREid Connect into the separated pieces. Last week, a number of things came together including the first public presentation of this project that I put up on YouTube, publicized by a very articulate practicing physician http://thehealthcareblog.com/blog/2016/01/23/the-patient-centered-health-re… , a major publication http://www.nejm.org/doi/full/10.1056/NEJMp1512142 by long-time academic collaborators of mine, and a bunch of behind-the-scenes activity leading to separate testimony in Washington this week by Eve and by me http://bit.ly/APItaskforce . In healthcare, as opposed to more typical commerce, patients have a "right of access" to our own health data which can be used to drive adoption of UMA by physicians and tech innovators. The major health IT conference in the US is coming up at the end of February and it's a major opportunity to promote UMA. *Need Help:* Michael Chen and I need help with our respective GitHub projects (NOSH and HIE of One) in order to complete the proof of concept while the regulators and geeks are still firming up the healthcare standards and profiles. I am particularly lame and am hoping to get some coding help around HIE of One which I'm building around Debian/FreedomBox at https://github.com/HIEofOne/PersonalAS/wiki/Milestone-1:-OpenID-Connect-Cli… As you can see there, the FreedomBox community will also help and help drive adoption. I think Roland's UMA code for Python could do much of this and, because NOSH is using MITREid Connect, the result would be more broadly interesting. Can any umanitarian help add an UMA AS to FreedomBox? Thanks, Adrian -- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

1 0

Reminder: no WG or legal subgroup meeting this week
by Eve Maler 19 Jan '16

19 Jan '16

If you have *action items*, this is a great chance to try to complete them. (I'm aware that several are weighing on my own head. :-) Also, our 2016 APAC-friendly sync meetings don't start up again until next week. As always, you can check the meeting schedule by looking at our online *calendar* <http://kantarainitiative.org/confluence/display/uma/Calendar>. If you haven't received an *invitation* to any of these meeting series and would like to, drop me a private note and I'll add you. Also, if you'd like to receive *Skype* pings about impending meetings a few minutes before they start, let me know your Skype handle and I'll add you to our chat group. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Deriving UMA [Legal] from the law and one simple assumption
by Adrian Gropper 16 Jan '16

16 Jan '16

In the last month two very important regulatory guidance documents have been released by the EU and US governments respectively: http://europa.eu/rapid/press-release_MEMO-15-6385_en.htm and http://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.ht… By adding to these regulations a single constraint - that an individual can own and specify the UMA Authorization Server if they choose to - I think we can derive a complete UMA Legal profile and associated clauses. I've started analysis of the US reg at http://bit.ly/HEARTfromHIPAA I think a similar analysis could be interesting for the EU regs. Adrian -- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

5 8

Notes from UMA legal subgroup telecon 2016-01-15
by Eve Maler 15 Jan '16

15 Jan '16

*Please note:* No meeting next week! We'll resume the week after. http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes 2016-01-15 - Review the emerging WG roadmap use cases <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-01-14> - Discuss the "RO access limit discretion" use case <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-01-14> - Discuss other open editorial issues for the candidate model text <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative…>, as outlined in previous meeting notes below Attending: Eve, Ann, Adrian, Jim, Jon, Mark, Sal, Thomas What Eve calls the "Adrian clause" is this part of UMA Core Sec 3.3.3 <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#give-acce…>: "The resource server MAY apply additional authorization controls when determining how to respond." What does the "RS authorization discretion" use case mean? Should the AS be made officially aware that the RS still didn't give access (similar to the "Shoebox" technical idea), or could the RS somehow need some other assurances that it can be compliant? This goes right back to the Adrian clause, and complementarily, to the Shoebox idea. The RS could either warn Alice, or could verify the requesting party on its own. Is this broad-based, or truly healthcare-specific? To how many jurisdictions does it apply? Adrian suggests another case of a warning. A data processing process might take some time to complete, and only licensed practitioners can receive in-process results. Would it be useful to develop a model clause, or even a pair of model clauses? Sounds like it's useful to try, and then go back and see if it's getting used. What does the "RO access limit discretion" use case mean? There is something of an opposite to the Adrian clause in the same section: "The resource server MUST NOT give access in the case of an invalid RPT or an RPT associated with insufficient authorization." A way of looking at it is: - Conditions: RO wants sharing to happen; AS executes those directions appropriately, such that the RPT is valid and is associated with sufficient authorization data: - RS gives access - normal case - RS doesn't give access - To remain compliant with the law of some jurisdiction - MUST PRODUCE NOTIFICATION? - For some other reason - MUST NOT HAPPEN WITHIN AN UMA FLOW GOVERNED BY THE PAT MINTED WITH THE AS ABOVE? - Conditions: RO doesn't want sharing to happen; AS executes those directions appropriately, such that the RPT is invalid or is associated with insufficient authorization data: - RS doesn't give access - normal case - RS does give access - To remain compliant with the law of some jurisdiction - MUST PRODUCE NOTIFICATION? - For some other reason - MUST NOT HAPPEN WITHIN AN UMA FLOW GOVERNED BY THE PAT MINTED WITH THE AS ABOVE? The idea of getting notices is that the RO could severe the relationship with the RS if they want. Of course, sometimes there are legal constraints on even getting a notification. Can you ever trust the AS to serve the RS, versus the RO? Only at the business agreement level could an AS start to consider jurisdictional issues that RS's care about. *Please note:* No meeting next week! We'll resume the week after. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA legal subgroup telecon 2016-01-15
by Eve Maler 14 Jan '16

14 Jan '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes UMA legal subgroup notesDate and Time - *Fridays,* 8-9am PT - Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540# - Screen sharing: http://join.me/findthomas - *NOTE:* *IGNORE* the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar ------------------------------ 2016-01-15 - Review the emerging WG roadmap use cases <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-01-14> - Discuss the "RO access limit discretion" use case <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-01-14> - Discuss other open editorial issues for the candidate model text <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative…>, as outline in previous meeting notes (see link above) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from UMA telecon 2016-01-14
by Eve Maler 14 Jan '16

14 Jan '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-01-14 MinutesRoll call Quorum was not reached. Quick legal subgroup update The subgroup meetings are going to continue, and consensus was reached on releasing beta model text by the end of Q1. Update on AIs from last week Andi now has the data he needs for the blog post. We need to publish the specs first; that should happen tomorrow. Mike is doing a Kantara blog post <http://www.gluu.org/blog/gluus-rsa-conference-2016-events/> about RSA sessions, including those that relate to UMA (and beer!), and can mention others. Eve is doing a privacy talk with Josh Alexander (and they'll be singing again too [image: (smile)]). A good idea is to send calendar invitations to those you'd really like to come to your talk. Hopefully Kantara will be sponsoring the Non-Profits on the Loose party again at RSA! Keep on the lookout. Even if not, let's all try to get together and hoist an UMArtini (or something – or a BLT...). Thomas and Maciej and Eve are very close to finishing other AIs. Review roadmap use case/technical issue matrix (Eve AI) and figure out what to dive into/how/when in Q1 - - Good F2F opportunities? - Good liaison opportunities? - Charter AIs? We are looking for "customer need" for these use cases and technical issues. Let's put initials of participants where they can confidently express "customer need" in 2016 or 2017 (or, if you want to remain pseudonymous, get in touch with Eve and she will put XX in for your initials). use case technical issue IoTAPI securityfederated authz RS authorization discretion (also "legal"?) RO access limit discretion (also "legal")wide ecosystems (is this a meta- use case?) access federations ("legal") AAT burden permission reg extension MSclient-to-AS-first efficiency MSself-contained token validation RPT needs refresh token* Shoebox endpoint* An issue that Mike wants UMA to explore is the new NAPPS solution <https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00> being proposed that uses PKCE. It leverages new system browser capabilities to return control to a native app using a custom scheme that the native app registered. Could this solution be applied to how a client delivers an RPT to a mobile app? Since the client just makes a direct back-channel call to the RPT endpoint at the AS, is this needed? Perhaps not right now, but maybe this could be used where we use a redirect flow (redirecting Bob for claims gathering after getting need_info with redirect_user), or if we start considering an authorization code-type flow for a redesigned client interaction with the AS a la Justin's suggestion (AAT-free). Mike remarks that a self-contained token is interesting but may be a nice-to-have for him vs. a self-contained token. In the work he's describing here <http://ox.gluu.org/doku.php?id=uma:oauth2_access_management>, the client-to-AS-first pattern could be relevant. Adrian would like an RS to be able, based on jurisdictional requirements, to get hold of verified attributes of the requesting party. This likely goes beyond healthcare, he surmises. What happens if the RS trusts the AS to be the RO's agent but doesn't trust the AS to make proper authorization decisions on behalf of the RO (e.g., by assessing verified attributes presented by the RqP)? Currently UMA says that if the RS cares about such attributes, it can gather them locally; it doesn't (by default) get them from the AS. Are we interested to develop a token profile for this to come from the AS? Perhaps there's not enough impetus. What about a "Shoebox" endpoint? The AS could present this endpoint for more than "consent receipts" – importantly, notifications are a big part of many laws. It would be great to bounce this off our legal subgroup. Is it, in fact, right for the AS to take on such an endpoint? What "RO access limit discretion" means is that we want to set up a one-way valve. Currently the spec it's a MUST, but technically it's not possible to enforce that the RS not give access when the permissions in the RPT say "no" in a technical fashion. However, it may be possible to set up a conformance suite in such a fashion to catch such cases and force the throwing of an audit log entry. In fact, this could be a case where a "Shoebox endpoint" could be a key part of a technical solution, in that we could mandate notices for certain kinds of access given. *AI:* Eve: Put starred items in the left column into GitHub issues. AI: Eve: Post matrix in a more prominent wiki place and start to check off relationships among the columns and rows, and advertise the opportunity to state priorities. Attendees As of 18 Dec 2015, quorum is 6 of 11. (Evariste, François, Domenico, Sal, Thomas, Andi, Robert, Maciej, Eve, Søren, Mike) 1. Eve 2. François 3. Domenico Non-voting participants: - Steve - Katie - Adrian - George *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2016-01-14
by Eve Maler 12 Jan '16

12 Jan '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-01-14 Date and Time - *Thu Jan 14,* 9-10am PT - Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540# - Screen sharing: http://join.me/findthomas - *NOTE:* *IGNORE* the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2016-01-17 if quorum - Quick legal subgroup update - Update on AIs from last week - Review roadmap use case/technical issue matrix (Eve AI) and figure out what to dive into/how/when in Q1 - Good F2F opportunities? - Good liaison opportunities? - Charter AIs? - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from UMA legal subgroup telecon 2016-01-08
by Eve Maler 08 Jan '16

08 Jan '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes 2016-01-08 - Review proposed mission and timeline <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/-xxfPj0xJ…> - Review high-level requirements <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/-xxfPj0xJ…> - Review latest candidate model text <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative…> Attending: Eve, Ann, Jim, Adrian, Jon, Mark, Thomas, Bill Wendell (guest - ears only), Andrew Hughes, Sal Mission and timeline discussion A proposed mission and timeline were sent in this message <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/-xxfPj0xJ…> . Jon speaks in support of the three goals. Is "model clauses" the right phrase, given that "EU model clauses" is something of a term of art? We're free to call it whatever we want. RoboClauses? [image: (smile)] Maybe the connection to EU model clauses is helpful to us. Regarding meeting scheduling, if text review is paramount in the early going, availability of interested parties is the most key. Offline review and reporting of comments by others could work great. "Model text" was Eve's temporary phrase covering not just the clauses but also the definition. "Model T – you can start with any color you want, as long as it's black!" We're thinking that the "standard" meeting time of Fridays at 8am PT would be okay for starters in working on the model text. Note that Eve can't make January 22, so maybe we can move or skip that one. Andrew's project is holding a F2F in January, and by February will possibly be really ready to need our outputs. Right now they're wrestling with different views on what "authorization" means. Is it authorization to release information? access to an API? (UMA would rely on the semantics of the API being protected for the definition.) Mark notes that consent and permission definitions should come into the picture as well. This does actually impact our term definitions because we use the word "Authorization" as part of our UMA role names, and so we may have to define Authorization, or at least define it in a limited sense so that a context in which the word is defined in a different sense is not incompatible or confusing wrt our usage. If there is, somewhere (EU?), a standard vocabulary, can we leverage it? Or is it too backwards-looking? Let's add this to our open issues. *AI:* Eve: Add model text issues to our issues backlog and tag them appropriately, including the issue of defining authorization, consent, etc. Consenus on the mission is positive. What should our timeline actually be? Jim recommends that we target a real version number of 1.0. We can achieve this sooner rather than later if we have real review by people who really need this text! Eve has been collecting external reviewer candidates. We did some more brainstorming. The right time for a beta version of the model text for review: end of March 2016. *AI:* Eve: Send continuing calendar invitations. Requirements discussion Some proposed high-level requirements were sent in this message <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/-xxfPj0xJ…> . Eve did a quick reading of the proposed high-level requirements. People started dropping off, but it sounded like there was at least some weak rough consensus. [image: (smile)] We'll work with this list for now until it proves problematic. Draft model text The latest model text for review, with commentary, was sent in this message <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/j5hKnR6VB…>. It lives persistently here <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative…> . We took a quick look at the message sent out. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

[Legal] Model text for review
by Eve Maler 08 Jan '16

08 Jan '16

Rather than worry (for now) about the form of documents that use our model text, we thought we would home in on just the term definitions, abbreviation definitions, and model clauses -- what we're collectively calling "model text". We're only partway towards an editor's draft reflecting the feedback we gathered last time. Model text items needing review and work: - Term and abbreviation definitions (revised, and red taken off token names) - Multi-party conditions and duties to pairwise (partially revised) - Distinguishing between delegatable and nondelegatable rights and responsibilities (possibly leveraging CARAT <http://civics.typepad.com/files/carat_final_011400-1.pdf>) (not revised) - Considering the need for conditions subsequent - The need for clauses dealing with security layers underneath UMA (see issue notes below) - Considering issue notes sprinkled throughout existing clause text - ...? The link we'll use persistently for the draft model text needing review is: http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative… If you go there now, you'll see a kind of table of contents, with entries for 0.md, Candidate, Clause, Comment, Terminology, and Z. If you go into 0.md and click the Document link at the top, you'll get an expanded view of the model text. If you go into Candidate, you'll see a list of pairwise "conditions" that will help us explode our too-complex multi-party conditions to meet the goal we discussed last time for breaking down all relationships between parties into pairs. Here is the analysis gone through to get this set of conditions for a large subset of the existing clauses, namely the relationships among the Authorizing Party (Alice), the Authorization Server Operator, and the Resource Server Operator, which end up getting bound by a protection API token or PAT. (Note that the clauses exposed in 0.md don't yet list out "multi-conditions" yet.) Conditions (my names here were informal; Jim gave them slightly different names in the file and we can change them at will): - RSO-ASO role establishment: For the period that the Resource Server Operator and Authorization Server Operator have mutually agreed to serve in these respective roles for each other - RSO-AuthzP role establishment: For the period that the Resource Server Operator and Authorizing Party have mutually agreed to serve in these respective roles for each other - ASO-AuthzP role establishment: For the period that the Authorization Server Operator and Authorizing Party have mutually agreed to serve in these respective roles for each other Duties that depend on all three conditions (links here are to files linked off of 0.md's Source view <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> ): - (depending on what we decide regarding the discussion about respecting permissions) Duty.1 of AP_Delegate-Protection_0.md <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> (probably modified to clarify that it reserves the right to apply its own local authorization processes) - Duty.1 of ASO_Register-Accurately-and-Timely_0.md <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> (only to AuthzP, not also to ASO? why does it owe this to the ASO?) - (depending on what we decide regarding the discussion about respecting permissions) Duty.1 of Respect-Permissions <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> -- or maybe it will end up being Disallow-Access-On-Insufficiency or something - Duty.1 of Follow-Policies-Accurately-and-Timely <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> (only for AuthzP, not also to RSO? why does it owe this to the RSO?) Continuing the exercise, we didn't give Introduce-Authorization-Server <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> and Introduce-Resource-Server <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…>, respectively, the right condition because what precedes them is actually the process of the Authorizing Party consciously identifying which partner they want the other one to work with, not already having a valid PAT. So it needs to be something like this instead: Conditions: - ASO choice acceptable to RSO: When more than one choice of an Authorization Server Operator is acceptable to a Resource Server Operator - RS nondefault AS choice interface: When the Resource Server has presented an interface to the Resource Owner that does not default to an automatic choice of Authorization Server - RSO meets ASO client credentials requirements: When the Resource Server has met any requirements for acquiring OAuth client credentials - (maybe need other security precautions here, about OAuth redirects and registered callback endpoints? or can that be commentary?) Duty: - Duty.1 of Introduce-Authorization-Server <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> (probably reworded to be more formal) Conditions: - No preestablished ASO relationship with RSO: When the Authorization Server Operator has no preestablished relationship with the Resource Server Operator - RSO meets ASO client credentials requirements (haha, reuse again) - (maybe need other security precautions here, about OAuth redirects and registered callback endpoints? or can that be commentary?) Duty: - Duty.1 of Introduce-Resource-Server <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> (probably reworded to be more formal) Out of all the clauses originally written, this leaves only the following to be analyzed afresh. - Adhere-to-Terms in both directions - Supply-Truthful-Claims - Is-Legitimate-Bearer - Request-Limited-Claims *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0