[Openid-specs-heart] Openid-specs-heart Digest, Vol 30, Issue 9

Fri Jul 31 15:40:15 UTC 2015

Briefly and probably oversimplifying: IDESG is a private-sector-led
steering group that advises the US public-sector National Strategy for
Trusted Identities in Cyberspace initiative administered by NIST. NSTIC has
been offering funding grants to boost experimentation around technologies
and concepts that strengthen the notion of a trusted, privacy-sensitive
identity ecosystem (meaning, lots of parties interacting securely), which
has many similarities to what we're striving for here (though not
health-sector-specific, and US-driven vs. international). Many of the same
folks work in both spaces, many of the same technologies crop up in both
spaces.

I just went and looked at the "baseline functional requirements" for the
framework <https://www.idecosystem.org/filedepot>, and they're quite a bit
different from the type of thing we're working on, though. While we are
producing concrete profiles of existing protocol specifications for
hands-on usage by developers and deployers, it looks like they are way up
in the "stack" of deployment.

FWIW and YMMV :-),

*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/> community!

On Sat, Jul 25, 2015 at 4:25 AM, Danny van Leeuwen <danny at health-hats.com>
wrote:

> I would like to know more about IDESG Identity Ecosystem Steering Group,
> Inc. Seems critically important to the openid-heart work. I don't
> understand the *Identity Ecosystem Framework".*
>
> On Fri, Jul 24, 2015 at 8:00 AM, <
> openid-specs-heart-request at lists.openid.net> wrote:
>
>> Send Openid-specs-heart mailing list submissions to
>>         openid-specs-heart at lists.openid.net
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         http://lists.openid.net/mailman/listinfo/openid-specs-heart
>> or, via email, send a message with subject or body 'help' to
>>         openid-specs-heart-request at lists.openid.net
>>
>> You can reach the person managing the list at
>>         openid-specs-heart-owner at lists.openid.net
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Openid-specs-heart digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: Vectors of Trust - HEART Edition (Adrian Gropper)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Thu, 23 Jul 2015 14:01:46 -0400
>> From: Adrian Gropper <agropper at healthurl.com>
>> To: "openid-specs-heart at lists.openid.net"
>>         <openid-specs-heart at lists.openid.net>
>> Subject: Re: [Openid-specs-heart] Vectors of Trust - HEART Edition
>> Message-ID:
>>         <
>> CANYRo8j_bE0oXgUKAf3psJCwZw8Csg+5c5Q6b329woBPm453NQ at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Genomic and other family-related protected resources is another reason
>> FHIR
>> must allow a patient-specified UMA authorization server. Without UMA,
>> there's no hope of coordinating access to family-related info. Here's a
>> good example.
>>
>> https://github.com/offapi/rbac-23andme-oauth2
>>
>> My 23andMe genetic profile is already out there ready to be used in all
>> sorts of ways. My release of this information impacts my entire family.
>> Unless me and my family members can each choose their OAuth authorization
>> server with UMA, what hope do we have of coordinating the release of this
>> kind of information to various third parties?
>>
>> Adrian
>>
>>
>>
>> On Tue, Jul 21, 2015 at 5:09 PM, Adrian Gropper <agropper at healthurl.com>
>> wrote:
>>
>> > A post about harmonizing the Argonaut and HEART approaches to FHIR:
>> >
>> >
>> >
>> http://thehealthcareblog.com/blog/2015/07/20/standards-alone-are-not-the-answer-for-interoperability/
>> >
>> > Adrian
>> >
>> > On Fri, Jul 17, 2015 at 7:52 AM, Adrian Gropper <agropper at healthurl.com
>> >
>> > wrote:
>> >
>> >> I think all of us agree with Jocelyn Samuels that health data privacy
>> and
>> >> security can coexist (
>> >>
>> http://www.fiercehealthit.com/story/jocelyn-samuels-privacy-and-data-sharing-can-coexist/2015-06-04
>> >> ). What does this specifically mean in the context of HEART and our
>> current
>> >> conversation about OAuth and UMA profiles?
>> >>
>> >> I'm adopting the phrase "vectors of trust" for this discussion because
>> I
>> >> think it applies to authorization in the same way it does to
>> >> authentication. (For those that wish to dive in, there's a major
>> healthcare
>> >> patient authentication discussion underway in IDESG that you can ask me
>> >> about.)
>> >>
>> >> Do scopes have anything to do with vectors of trust in the HEART
>> >> authorization model? I'm having a hard time following the current
>> >> discussion about scopes and how they relate to SMART on FHIR and
>> Argonaut.
>> >> To avoid the compromise of privacy vs. security we need to deal with
>> the
>> >> vectors of trust _before_ we profile scopes. This may be more true of
>> UMA
>> >> than it is for OAuth but I think it applies to both.
>> >>
>> >> To avoid a compromise between security and privacy, the RS must be
>> >> granted a safe harbor for API access by the authenticated and
>> autonomous
>> >> resource owner. This protects the security interest of the RS and the
>> >> privacy interest of the RO.
>> >>
>> >> The trust relationship between RS, AS, and Client must be designed to
>> >> meet our Charter which includes a requirement of an "independent AS"
>> that
>> >> could be built by the RO. This is absolutely key to the scalability and
>> >> generativity of HEART.
>> >>
>> >> It's less clear about how HEART will deal with a "built" Client or a
>> >> client that is trusted only by the AS but not the RS. Who decides if
>> the
>> >> Client can participate in the "safe harbor by the authenticated and
>> >> autonomous resource owner" contract? The profiling we do around OAuth
>> and
>> >> UMA should be able to solve this problem and it should probably be done
>> >> ahead of the scopes discussion.
>> >>
>> >> I believe that once we understand the issues of an independent AS and
>> of
>> >> Client trust the difference between UMA vs. OAuth profiles, including
>> >> scopes, in any particular use-case, will be easy to resolve.
>> >>
>> >> Adrian
>> >>
>> >> --
>> >> Adrian Gropper MD
>> >> Ensure Health Information Privacy. Support Patient Privacy Rights.
>> >> *http://patientprivacyrights.org/donate-2/*
>> >> <http://patientprivacyrights.org/donate-2/>
>> >>
>> >>
>> >
>> >
>> > --
>> > Adrian Gropper MD
>> > Ensure Health Information Privacy. Support Patient Privacy Rights.
>> > *http://patientprivacyrights.org/donate-2/*
>> > <http://patientprivacyrights.org/donate-2/>
>> >
>> >
>>
>>
>> --
>> Adrian Gropper MD
>> Ensure Health Information Privacy. Support Patient Privacy Rights.
>> *http://patientprivacyrights.org/donate-2/*
>> <http://patientprivacyrights.org/donate-2/>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150723/b3454bd7/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>>
>> ------------------------------
>>
>> End of Openid-specs-heart Digest, Vol 30, Issue 9
>> *************************************************
>>
>
>
>
> --
> Danny van Leeuwen
> 617-304-4681
>
> *Blog www.health-hats.com <http://www.health-hats.com/> discovering the
> magic levers of best health*
> *Twitter **@healthhats*
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150731/db99a54b/attachment.html>