- WG-UMA - mailman.kantarainitiative.org

Agenda for UMA telecon 2020-11-05
by Alec Laws 05 Nov '20

05 Nov '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-11-05 Date and Time Alternate-week Thursdays 10am PT Screenshare and dial-in: https://global.gotomeeting.com/join/485071053 <https://www.google.com/url?q=https://global.gotomeeting.com/join/485071053&…> United States: +1 (224) 501-3316, Access Code: 485-071-053 See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar <http://kantarainitiative.org/confluence/display/uma/Calendar> Agenda Approve minutes of UMA telecon 2020-10-15 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-10-15>, 2020-10-22 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-10-22>, 2020-10-29 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-10-29> Policy Manager <https://github.com/KantaraInitiative/wg-uma/blob/master/uma_policy_manager.…> draft text IIW recap AOB

1 0

Congratulations -- For Consent Receipt Supporters
by Mark Lizar 05 Nov '20

05 Nov '20

Hello All, Not sure if anyone has had a chance to review this EU Data Governance document ? (Attached) recital 25 - ” Consent Dashboards provide an aggregate view of all consent statements given digitally based on ‘consent receipts’ for managing relationships between organisations that the data subject would like to give data access too.” and 34 - to bring legal certainty to withdraw of consent”. - this has been a big part of the lobby and advocacy of work here. And it is really incredible to see it in this document. :-) Congrats Kantara and everyone who has supported the work . - Mark

2 1

Draft minutes of UMA telecon 2020-10-29
by Eve Maler 29 Oct '20

29 Oct '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-10-29 MinutesRoll call Quorum was not reached. Approve minutes - Approve minutes of UMA telecon 2020-10-15, <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-10-15> 2020-10-22 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-10-22> Deferred. Chair and legal editor positions <https://kantarainitiative.org/confluence/display/uma/Leadership+Team> up for annual term - Taking nominations Policy Manager <https://github.com/KantaraInitiative/wg-uma/blob/master/uma_policy_manager.…> draft text Alec has worked on some user stories (attached to the minutes doc), going back to some of his original work. He has incorporated some of our "wide-ecosystem" and "client trust" thinking. What ecosystem, specifically, is wide here? Adrian's goal tends to be that the RO gets total control ("self-sovereign", not classic federation). Alec struggles with SSI in that the wallets have no certification. Could the AS help with that role? Alec suggests there are two themes: interoperability between the RS and client, and integration. Or maybe better stated, it's "data model" vs. "trust model". They get really conflated all the time. FedZ Sec 1.4 <https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0…> says "The resource server defines the boundaries of resources and the scopes available to each resource, and interprets how clients' resource requests map to permission requests, by virtue of being the publisher of the API being protected and using the protection API to communicate to the authorization server." That's *data model* stuff: the RS defines its data model, and that of necessity collapses the trust model to some extent (narrows the ecosystem of potential clients somewhat) because only some clients will ever work with that data model. Standard data models such as FHIR are intended to widen ecosystems: to make it possible for more clients to work. The Resource Definitions solution was meant to try and ease the fact that the onus falls on the client to say what profile of the API it supports. There has to be some *trust model* between RS/AS/C, that is, a certifying party. The IdP in OIDC maintains its own client list. What is the case in UMA? The RO might or might not have total control of an AS they use. The AS could have a number of ways to control whether a client (vs. a RqP) is sufficiently untrustworthy that it: a) doesn't get client credentials (say, because it doesn't have a good software statement); 2) isn't allowed to continue with the token-getting protocol; or 3) doesn't get an RPT or permissions it needs for access. The RS could use the Adrian clause. But on what basis – does the RS see the client's software statement? No, not at least within an UMA context. It could detect a device footprint or similar. Let's say we're applying UMA hypothetically to the Data Transfer Project <https://datatransferproject.dev/>, which is very RS-centric, and ROs can choose their AS. It serves a population of users, which constrains clients by API type, making the ecosystem not perfectly "wide". People's relationships with RS's today include a bundled AS/IdP. UDAP is an example of an RS/AS/C certifying party. It's about the trust model, not about the data model, and it's about the trust model in an OAuth context. Some people think UDAP and UMA are stark alternatives, but this analysis helps us start to show how this doesn't seem to be true. We think we can make progress by applying the data model/trust model analysis and Alec's user stories. Nancy is connected to the new DS4P work and can keep us in the loop, along with reaching out to Alec with her thoughts on consent servers. Attendees As of October 26, 2020, quorum <http://kantarainitiative.org/confluence/display/uma/Participant+Roster> is 5 of 9. (Michael, Karim, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve) 1. Michael 2. Domenico 3. Alec 4. Eve Non-voting participants: 1. Adrian 2. Nancy 3. Kate 4. Scott 5. Colin Regrets: - Andi - George *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2020-10-29
by Eve Maler 28 Oct '20

28 Oct '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-10-29 Date and Time - *Primary-week Thursdays 6:30am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/485071053 <https://www.google.com/url?q=https://global.gotomeeting.com/join/485071053&…> - United States: +1 (224) 501-3316, Access Code: 485-071-053 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Approve minutes of UMA telecon 2020-10-15 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-10-15> , 2020-10-22 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-10-22> - Chair and legal editor positions <https://kantarainitiative.org/confluence/display/uma/Leadership+Team> up for annual term - Policy Manager <https://github.com/KantaraInitiative/wg-uma/blob/master/uma_policy_manager.…> draft text - AOB *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2020-10-22
by Eve Maler 26 Oct '20

26 Oct '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-10-22 MinutesRoll call Quorum was not reached. Approve minutes - Approve minutes of UMA telecon 2020-10-15 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-10-15> Deferred. Policy Manager <https://github.com/KantaraInitiative/wg-uma/blob/master/uma_policy_manager.…> draft - review text - Policy data model email <https://groups.google.com/g/kantara-initiative-uma-wg/c/k9LlfGGzLY0> sent by Alec The one needed field is to specify the required values in order to achieve interoperability. Alec's first attempt at an example is for something like a Google Doc Share button for Comment access. The second example starts to get hairy. In specifying required claims, how long can we avoid starting to define a "minimum viable required claims language" for ROs to use that "doesn't need to look like a policy language"? In the solutions with which Identos has deployment experience, how much flexibility does the RO really need? Not much, because the community AS sort of manages to limit the options in a reasonable manner given the actual community. The APIs and scopes are fixed, the packages of client requests are fixed, and so what the clients can get access to is fixed, and in their specific case, the RqP == the RO. For dynamic APIs that rely on an ID token for invocation context, like FHIR with patient ID, UMA becomes less friendly. Even dictating "required claims", we're sort of getting into the policy game a little bit. It seems like a slippery slope. And yet we don't think the RO really cares about the choice of language. An architecture where the AS would be a client of policy information points (PIPs) that could all speak the same policy language by agreement, even if the RO joined each pair together through OAuth in "protection API" fashion, would still be "paternalistic" rather than "self-sovereign" in outlook, though. Our approach is intended to empower the RO more than that (and thus focuses on a client application the RO is able to choose). We need to get clearer on our use cases/user stories. Our sample UX illustrated by Domenico doesn't (yet?) illustrate what happens if the client app interacts with multiple AS's. Can we construct user stories about what the RO wants to have happen when they have multiple AS's? multiple RS's (with resources that could be shared (and thus policy))? multiple RqP's necessitating sharing (and thus policy)? The answers to all this will dictate just what we need to solve in terms of policy and "required claims" interoperability. Alec is going to try to construct some. Attendees As of October 22, 2020 (pre-meeting), quorum is 6 of 11. (Michael, Karim, Domenico, Mike, Peter, Sal, Gaurav, Thomas, Andi, Maciej, Eve) 1. Michael 2. Peter 3. Eve Non-voting participants: 1. Alec 2. Scott 3. Kate 4. Anik Regrets: - Andi *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2020-10-22
by Eve Maler 22 Oct '20

22 Oct '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-10-22 Date and Time - *Alternate-week Thursdays 10am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/485071053 <https://www.google.com/url?q=https://global.gotomeeting.com/join/485071053&…> - United States: +1 (224) 501-3316, Access Code: 485-071-053 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Approve minutes of UMA telecon 2020-10-15 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-10-15> - Policy Manager <https://github.com/KantaraInitiative/wg-uma/blob/master/uma_policy_manager.…> draft - review text - AOB *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

Policy data models
by Alec Laws 22 Oct '20

22 Oct '20

Hi all, Please find some notes on possible data model for the policy resource. Currently looking at uma required_claims, did/vc, rar and zcap Cheers, - Alec ## UMA style required_claims pulled from UMA Grant: ``` required_claims An array of objects that describe the required claims, with the following subparameters: claim_token_format OPTIONAL. An array of strings specifying a set of acceptable formats for a claim token pushed by the client containing this claim, as defined in Section 3.3.1. Any one of the referenced formats would satisfy the authorization server's requirements. Each string MAY be a URI. claim_type OPTIONAL. A string, indicating the expected interpretation of the provided claim value. The string MAY be a URI. friendly_name OPTIONAL. A string that provides a human-readable form of the claim's name. This can be useful as a "display name" for use in user interfaces in cases where the actual name is complex or opaque, such as an OID or a UUID. issuer OPTIONAL. An array of strings specifying a set of acceptable issuing authorities for the claim. Any one of the referenced authorities would satisfy the authorization server's requirements. Each string MAY be a URI. name OPTIONAL. A string (which MAY be a URI) representing the name of the claim; the "key" in a key-value pair. ``` ADD NEW field ``` value: the required value(s) of this claim?? ``` Q. I don't understand the distinction between claim_type, name (and display_name) A? The name is the expected 'key' in the token, and the claim_type is how to interpret that key??? As defined by the AS since it interprets the claims? Let's try to represent a policy as would be used by google drive to share a file. This is the same as would be presented to the client (@ token endpoint) without the 'values' field ``` resource_id: 'some docuement', resource_scopes: [ comment ] required_claims: [ { "claim_token_format":[ "http://openid.net/specs/openid-connect-core-1_0.html#IDToken", "https://w3c-ccg.github.io/zcap-ld/" // NEED AN EXAMPLE ZCAP TO MEET A POLICY ], "claim_type":"email", "issuer":[ "https://example.com/idp", "https://google.ca" ], "name":"email_key_in_token" "values": ["bob(a)gmail.com", "cary(a)email.com", "denis(a)example.com"] }, ] ``` How about to share my patient record with any researcher from university. I need their sub to record access. ``` resource_id: "fhirrs.com/fhir/patient", scopes: [ read ] required_claims: { "claim_token_format":[ "http://openid.net/specs/openid-connect-core-1_0.html#IDToken", ], "claim_type":"sub", "issuer":[ "https://university.com/idp", "https://seamlessaccess.com/idp" ], "name":"sub" }, { "claim_token_format":[ "http://openid.net/specs/openid-connect-core-1_0.html#IDToken", ], "claim_type":"purpose", "issuer":[ "https://university.com/idp", "https://seamlessaccess.com/idp" ], value: "research" } ``` Requiring agreements to a specific purpose/tos/ethics statement ``` { "claim_token_format":[ "JWT" ], "claim_type":"tos", "issuer":[ as.com tospresentingservice.com ], "name":"tos" value: 'http://tos.com/specific/statement' }, JWT payload = { iss: tospresentingservice.com tos: http://tos.com/specific/statement } ``` or it could require a consent receipt (the RO has given consent to the RqP, which they are redeeming) ``` { "claim_token_format":[ "kantara/consentreceipt/1.1.0" ], "claim_type":"consent_receipt", "issuer":[ ], }, claim payload = consent receipt json ``` Can the RO specify approved clients?? this doesn't seem to fit into required_claims... although the rqp may be choosing the client software? ``` { "claim_token_format":[ "JWT" ], "claim_type":"client_id", "issuer":[ "as.com" ], "name":"client_id" values: [ clienta_known_to_as, "http://clietnapp.ca" ] }, ``` Can the RO specify (required acr of rqp) ``` resource_id: "fhirrs.com/fhir/patient", scopes: [ read ] required_claims: { "claim_token_format":[ "http://openid.net/specs/openid-connect-core-1_0.html#IDToken", ], "claim_type":"acr", "issuer":[ "https://university.com/idp", ], value: 'urn:whatever:gold' }, ``` Notes/Questions: could the `issuer` also be the CA/TTP?? Or has to be the direct `iss` in presented token (ie the signer...). How can a policy say 'any token approved through this "trust framework"?' Can there be many required claims with the same name/claim_type?? ie, array of values with many required_claims... would/can claims_token_format differ? The client may only provide one claims at time through the token endpoint. Token endpoint can always return a new ticket with the 'remaining' required claims, until the policy is met or all are presented. The client could repackage many tokens into a jwt with claims_sources or such Even if all required_claims are presented, it can still result in a deny result! should there be the ability to apply policy against resource_id/scope sets, similar to the permission api? This need would vary depending on the resource type/registration model at the RS no clear way to create policy beyond... required claims from the rqp. Ex can/should the RO have any ability to influence expiration times etc Is it possible to make the presented claim a requirement of the client vs the rqp? If the iss is the AS, does it imply it requires interactive claims gathering? ## Looking at DID/VCs withing the uma required_claims schema we could fit vc as a claim type The id in the presented VC must match the value `did:whatever:didvalue` ``` { "claim_token_format":[ "https://www.w3.org/2018/credentials/v1 ], "claim_type":"did", "issuer":[ "did:whatever:issuerdid ], "name" : "id" "value":"did:whatever:didvalue" }, { "claim_token_format":[ "https://www.w3.org/2018/credentials/v1 ], "claim_type":"university_degree", "issuer":[ "did:whatever:issuerdid ], "name" : "id" "value":"did:whatever:didvalue" } ``` An issue here is that the RqP needs to know which DID to present to this AS in order to meet the policy. this only works if the Rqp knows the request is in the context of a specific RO (sort of...) to know which did to present This is the "same" as needing to know a email, however email is more public by definition while a did may be pairwise by design () VC's are a token package type like OIDC IDToken. There is some predefined, but extensible attribute sets, and arbitrary claims can be asserted by issuers about the rqp ## Looking at RAR https://tools.ietf.org/html/draft-ietf-oauth-rar-02 ``` "type": The type of resource request as a string. This field MAY define which other elements are allowed in the request. This element is REQUIRED. This field MUST be compared using an exact byte match of the string value against known types by the AS. The AS MUST ensure that there is no collision between different authorization data types that it supports. The AS MUST NOT do any collation or normalization of data types during comparison. This draft defines a set of common data elements that are designed to be usable across different types of APIs. These data elements MAY be combined in different ways depending on the needs of the API. All data elements are OPTIONAL. "locations": An array of strings representing the location of the resource or resource server. This is typically composed of URIs. "actions": An array of strings representing the kinds of actions to be taken at the resource. The values of the strings are determined by the API being protected. "datatypes": An array of strings representing the kinds of data being requested from the resource. "identifier": A string identifier indicating a specific resource available at the API. ``` As defined, a RAR is pushed by a RP to the AS to indicate what resource they want access to. This is quite similar to the UMA RS permission endpoint, where the RS indicates what resources (type/identifier) and scopes (actions) it interprets for the client request. I am not clear how this could be used to model RO policy (very useful in resource definitions/indicators context) Possibly it could be used to model the resource definition side (ie replace the simple resource_id/scopes above) such that policy can be applied more generally instead of against specific resources. The RAR json would sit next to one of the other policy formats (required_claims array) ## Looking at ZCAP It is the claim unto itself, unlike VC's there are no actual claims in the ZCAP The zcap allows the invoker to perform some action(?) against the root 'parentCapability' The car in the example, also defines the scopes in some ways. The parentCapability could be a ticket from the permission api "there are the resources and scopes I am delegating to X" The zcap can be registered as policy at the AS, or given directly from ro->rqp? The root parentCapability=resource_id, invoker=rqp required proof Not clear how the AS can make a decision over this policy if it's not in the delegation chain? How could it invoke the capability such that the RS would allow it? - Avoid this by making the AS issue the initial zcap to the PM, instead of from RS->PM... this hides the zcap between AS/PM so RS need not know about it (similar to required_claims) 1. PM resource api would return a ZCAP? 2. PM would push a delegatedCapability as a policy back to the AS 3. a RqP must invoke the policy when it tries to access the resource Examples from zcap spec (https://w3c-ccg.github.io/zcap-ld/) ``` DELEGATION FROM RS to RO??? (outside of RO?) {"@context": ["https://example.org/zcap/v1", "https://autopower.example/"], "id": "https://whatacar.example/a-fancy-car/proc/7a397d7b", // policy id "parentCapability": "https://whatacar.example/a-fancy-car", // resource id "invoker": "https://social.example/alyssa/#pubkey-for-car", // rqp key // arbitrary policy constraints "caveat": [ {"type": "ValidWhileTrue", "uri": "https://social.example/alyssa/ben-can-still-drive"}, {"type": "ExpiresAt", "uri": 2345564<some future timestamp>} ], // this would require the RS to initially grant Alyssa the capability "proof": { "type": "RsaSignature2016", "proofPurpose": "capabilityDelegation", "created": "2016-02-08T16:02:20Z", "creator": "https://whatacar.example/a-fancy-car#key-1", "signatureValue": "IOmA4R7TfhkYTYW8...CBMq2/gi25s="}} PRESENTATION (claims presentation): {"@context": ["https://example.org/zcap/v1", "https://autopower.example/"], "id": "urn:uuid:ad86cb2c-e9db-434a-beae-71b82120a8a4", "action": "Drive", "proof": { "type": "RsaSignature2016", // A linked data document can be an invocation if it has a // proofPurpose of capabilityInvocation and links to the capability // chain it is invoking "proofPurpose": "capabilityInvocation", "capability": "https://whatacar.example/a-fancy-car/proc/7a397d7b", "created": "2016-02-08T17:13:48Z", "creator": "https://social.example/alyssa/#key-for-car", "signatureValue": "..."}} ``` Delegation Policy from Alyssa to Bob ``` {"@context": ["https://example.org/zcap/v1", "https://autopower.example/"], "id": "https://social.example/alyssa/caps#79795d78", // Pointing up the chain at the capability from which Alyssa was // initially gained authority "parentCapability": "https://whatacar.example/a-fancy-car/proc/7a397d7b", // Alyssa grants authority specifically to one of Ben's // cryptographic keys "invoker": "https://chatty.example/ben/#key-33", // Alyssa adds a caveat: Ben can drive her car, unless she flips // the bit at this url "caveat": [ {"type": "ValidWhileTrue", "uri": "https://social.example/alyssa/ben-can-still-drive"}], // Finally Alyssa signs this object with the key she was granted // authority with "proof": { "type": "RsaSignature2016", "proofPurpose": "capabilityDelegation", "created": "2017-03-28T06:01:25Z", "creator": "https://social.example/alyssa/#key-for-car", "signatureValue": "..."}} ```

2 1

Draft minutes of UMA telecon 2020-10-15 (and revised wiki)
by Eve Maler 15 Oct '20

15 Oct '20

https://kantarainitiative.org/confluence/display/uma/Home https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-10-15 MinutesRoll call Quorum was reached. Approve minutes - Approve minutes of UMA telecon 2020-10-08 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-10-08> MOTION: Thomas moves to approve minutes of UMA telecon 2020-10-08 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-10-08>: APPROVED. Vice-chair role Time to fill this role once again. Eve nominates Alec (and he accepts). MOTION: Thomas moves and Andi seconds and Michael thirds!: Install Alec as vice-chair for a term of one year. APPROVED by acclamation. Yay! Policy Manager <https://github.com/KantaraInitiative/wg-uma/blob/master/uma_policy_manager.…> draft - review text - Ideally put comments in GitHub ahead of time Domenico has provided a UX sample of a "personal data wallet". Check out the new section on our User Experience page <https://kantarainitiative.org/confluence/display/uma/UMA+User+Experience#UM…> . The discussion of last week was: How to fill in the required_claims in the posted policy? Required claims already have a way to be put into JSON in UMA Grant. Only email (in last week's discussion) would come under that definition. Was RAR discussed last week? No, but other options were: JWT or OAuth (could be RAR <https://tools.ietf.org/html/draft-ietf-oauth-rar-02>now). There's SCIM (lots of kinds of claims), RAR, specific claims as in OIDC, VCs... George suggests focusing on the structure and critical aspects vs. the claims themselves. UMA even goes "meta" from claim structure by having "claim tokens" and formats for them since there are already so many. Should we lock down some likely formats? This is akin to a relying party saying "I need a particular kind of claim". We had discussed in the past a "hashed claims discovery" mechanism that might, in a secure fashion, allow the AS to specify specific claim values it needs through need_info (issue #254 <https://github.com/KantaraInitiative/wg-uma/issues/254>). If security concerns override, then the user could always be asked to interact with the AS. Do we need some better language around all the different "ecosystem topologies", or "deployment patterns"? For example, whether clients are third-party wrt the AS/RS is a "normal OAuth" choice (though many OAuth deployment have first-party clients). Whether RS's are third-party wrt the AS is an UMA-specific "wide ecosystem" choice. There are also choices around "where to put the IdP". Now with the current extension work, "policy manager colocated with AS" means "just UMA" (silently, though the spec doesn't strictly require that), while "policy manager colocated with RS" starts to require more interoperability and thus suggests the need for the extension work. Sal suggests "flat, hierarchical, decentralized". This starts to intersect (hah) with the Venn that Eve, Alec, and Adrian were working on over the last few weeks that tries to describe client trust relationships. Especially for public clients (e.g. mobile apps), we need to worry about client trust. That's not an UMA-specific problem, but we need to (continue to) be aware of it. Is there a way we could build in a DPOP mechanism in UMA? DPOP didn't exist at the time we published UMA Grant, so we only pointed to what was available at the time. UMA is deployed on other technology and context and it's important to be aware of and strengthen it. Eve is trying to distinguish "scope" from "purpose". The former has to do with the action the RS has to allow/deny when it gets the token. The latter has to do with what the RqP can do subsequently with the access it eventually got (e.g. use the data for marketing purposes). (See our very old "simple access authorization claims" work <https://kantarainitiative.org/confluence/display/uma/Simple+Access+Authoriz…> for a way to embed this in required claims!) The required-claims piece seems different from the other pieces in that required claim values need to be drawn from the RqP, while the others need to be drawn from the RO, in order to build a complete policy. Does policy need to be standardized for interoperability, or can it be handled like UMA Grant handles claim tokens and formats now? We think the latter. Alec will put in strawman solutions for both required claims (in claim token/format fashion) and policy overall (in similar fashion) for us to consider. Sal notes that ISO 29184 provides some nice controls around notice (for things like purpose). There is a draft ISO 25760 around consent receipts. Attendees As of September 3, 2020 (pre-meeting), quorum is 5 of 9. (Michael, Domenico, Peter, Sal, Gaurav, Thomas, Andi, Maciej, Eve) 1. Michael 2. Domenico 3. Sal 4. Thomas 5. Andi 6. Eve Non-voting participants: 1. Alec 2. Scott 3. George 4. Anik 5. Kate *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2020-10-15
by Eve Maler 15 Oct '20

15 Oct '20

Hi folks, we do have our call this morning in about an hour. Sorry not to have sent a formal agenda, but work on the Policy Manager extension continues. Eve Maler (sent from my iPad) | cell +1 425 345 6756

1 0

Agenda for UMA telecon 2020-10-08
by Eve Maler 07 Oct '20

07 Oct '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-10-08 Date and Time - *Alternate-week Thursdays 10am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/485071053 <https://www.google.com/url?q=https://global.gotomeeting.com/join/485071053&…> - United States: +1 (224) 501-3316, Access Code: 485-071-053 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Approve minutes of UMA telecon 2020-10-01 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-10-01> - Policy Manager <https://github.com/KantaraInitiative/wg-uma/blob/master/uma_policy_manager.…> draft - review text - Ideally put comments in GitHub ahead of time - AOB *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0