...
Attendees
Discussion
- we talked about purpose specification and the need to list and register purpose in order to make them externally referencable.
- this is important because of A) usability of CR for people, B) for adding trust marks (frameworks) to purpose C) mapping to oauth scopes
- We talked about how there are needs for different types of receipts: consent is 1 of them being consent to use PII - under law with a Privacy Policy i.e. an initial authorizations for use and storage PII with the law as a trust framework; then there would be authorisation receipts, delegation, awarding privledges, which are then under the remit of the Terms & Conditions.
- In this regard can we get clarity that A) licensing for use of PII is an authority that would happen under the T&C's?
- In the core specification, can we use the same format for both use of PII under privacy law, and for use and control of PII under T&C's?
- Can we map purpose specification to terms and conditions? i.e. Purpose - Category A: (is an action catgeory) for the licensed sharing and control of PII under the User ? Category B: Delivery of service,
- Can User control over purpose and data processing be translated in to access controls in UMA?
- Can purpose be mapped to permissions? i.e. permission to use a resource - like a microphone,
- Can purpose be mapped to oAuth Scopes?
- Can User control over purpose and data processing be translated in to access controls in UMA?
- Purpose Specification can be directly referenced, Justin explains that this is Data rayafication -
- Expression of data then reference to that expresssion externally -
- RDF - Specification may be a good referenec
- In the existing model
- we are using the JTI -
- 1. unique identifier - inside the purview of a single issuer
- 2. the issuer (is a unique) identifier
- This then would equal CR-Identifier (? can we confirm this)
- Each purpose would then be identified - part of the consent receipt
- Purpose 1
- Purpose 2
- Purpose 3
- This can be used to build into a single URI, or to a xpath spec, or a list - or -
- referring parts inside the consent receipts
- x-path - can do this and create sub-portions of documents. reference part of the data model by its member name. compare it ideally .
- this can then be the start of an external api for fetching and storing this stuff later
- list of available issuers ( not - a register)
- referring parts inside the consent receipts
- Agree that The MVCR scope should have the purpose specification feature built into the core for future use and extension. - Should be raised on the List in terms of putting this into the core specification.
- what does an external reference look like? - there are some best practice. - json version of xpath:
- should be in a list kept on the server and be in the specification - and should be a discussion point.
- Action: Mark will create a list and some simple instruction to begin with for purpose specification and then we can put this as a registry of purpose, policy and provider (which is needed in all use cases)
- .Action: To bring up on list: Other types of consent & authorization receipts - we should make a big list and see if the core receipt profile is salient across receipt types .s
- In the Oauth space – tied to authorization server,
- authorisation grant is made - i (the user) am authorizing this client to access resources on my behalf.
- whata policy is created
- when a ticket is used ot issue tokens.
- authorisations and for consent - and for delegation,
- Technical Work Under way
- Core Profile for MVCR v0.7 - : From Two Party Use Cases
- Use Cases Under way
- Two Party
- Three Party Use Cases
- Expression of data then reference to that expresssion externally -
...