I rewatched the video, and things seem to go by really fast. For me, the clearest explanation is the one in the BSC DG report:
http://tinyurl.com/bscdgreport (look for “Use Case: Prescription Writing Into a Patient’s Health Record”).
UMA seems to be able to work with all of this right now. It’s agnostic as to prescription business model and identity system (we even have a design principle about the latter).
Regarding UMA + consent receipts:
Agreed! I’d taken an action from a Legal call to reach out about this to Andrew, but we hadn’t reached firm conclusions about how to proceed. I can’t attend IIW wither. Will there be a critical mass of knowledgeable people there? Should we be setting up its own call Series, or piling onto an existing one? The UMA legal framework doc should be done by end of year, and it sounds like CR 1.1 also needs to happen.
Regarding resource registration as a locus:
Not sure I get this one. This action just protects the resources (makes them “share-able” by the AS but not consented to be shared with anyone in particular yet). There’s a whole other long chain of actions, some of which happens outside the scope of UMA, that are relevant (see the Legal discussions — hence why the call for the joint meetings came from there).
(Hmm. Legal folks: We haven’t been looking at resource registration as contributing to the legal layer, but in the past I have proposed ways in which scope descriptions could be extended to contribute to licensing terms...)
Eve Maler (sent from my iPad) | cell +1 425 345 6756
Here here !
This to me sounds like the beginning of a chorus for the first CIS consent receipt song. :-) also really like context ticket. The original name of the consent receipt was a consent ticket as well.
A key topic is to work out the priorities to focus on next. IIW would be a great place to talk receipts. (Sorry I won’t be there this year) As soon as we get this receipt to a v1.1 It would be great to move to a weekly call on the utility of a receipt for resource registration.
That being said - there has been the idea of a consent record spec /add on, as well as expand the consent receipt to a privacy receipt. If there are any requests or suggestions for more work related to consent please let us know.
Personally, the use of a receipt to administer rights per context - like withdraw consent is high on my list .
- Mark
Hi Mark,
I would welcome an UMA CIS call. I’m hoping that UMA resource registration is the first and best use of a consent receipt. I also hope the the receipt is signed in a non-repudiable way.
Adrian
Hi Adrian,
I like the context ticket, which seems to be a receipt, this is something that might be a great topic point for a joint UMA CIS call. We have a stack of things we want to do with the consent receipt work. In particular the use of receipt to capture the context of the transition and to auto generate the permissions/rights based operations for that context.
A top task and priority for the work is the expansion of the use of aa receipt (not only a consent receipt) as well as the use of a receipt forrights and preferences at aggregate. In a perfect world we would be able to put this in the right (multi-wg output in Kantara) structure and use it for bridging work for future use cases
Mark Lizar
CEO & Founder | Open Consent |
Trust is the new currency and its measured in the quality of Consent
+44 (0) 208 123 2476
Twitter @Smartopian
Well, since you brought up healthcare, I’d like to share the current state of our self-sovereign technology stack as a 2:25 min. video
https://youtu.be/N_3DbDZUTIg
Notice that we’re using pre-HEART access to the institutional health record. Also notice how self-sovereign identity tech allows both credentials and auditable transactions to occur directly between individual people without any institution or federation. Behind the scenes, there’s a lot of work being done around W3C and Rebooting Web of Trust to standardize the credential handler API.
From a person’s perspective, the credential handler and the authorization server are twins separated at birth. In healthcare, at least, federation is just a drag on innovation. UMA might do better by embracing the self-sovereign model.
Adrian
Just wanted to mention that the profiles from the HEART WG define a mechanism for handling the sensitive data (e.g. "STD metadata") described in the use case in this paper. The
slide deck linked from the HEART wiki
home page describes it briefly (see also the links to the specs).
It works like this in the UMA case. If the RS registers a scope corresponding to a sensitivity code when it's registering a resource*, if a client brings back an RPT without that scope for the resource, then the RS has to filter (redact) any of that kind of sensitive information out of the resource before giving access to it. It doesn't necessarily mean Alice has that kind of sensitive data (being sensitive to Alice's privacy), but registering the scope is essentially a declaration of ability to filter it.
*The HEART profiles are still UMA1, of course, so it's "resource sets", but I've just provided some info to help us step up to UMA2 profiling as soon as the time is right. :)
--
Adrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
--
Adrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.