[Openid-specs-heart] Draft HEART meeting notes 2015-07-27

Tue Jul 28 01:21:51 UTC 2015

Thanks as always for the awesome notes.

Re this item: "*Eve (and Justin?) will brainstorm to see if they can come
up with anything that is not captured by the planned semantic profiles.*" I
was actually hoping Justin (and possibly Josh) might put some thought into
"semantic profile" topics that go beyond OAuth scopes prior to next week's
meeting and send thoughts around in email. I'm happy to contribute to such
a thread, and/or to get on a 2/3-way brainstorming call if desired.

*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 Mon, Jul 27, 2015 at 2:31 PM, Sarah Squire <sarah at engageidentity.com>
wrote:

> Lots of spirited discussion this week. As always, feel free to add
> anything I might have missed.
>
> Attendees:
>
> Debbie Bucci
>
> Casey Quinlan
>
> Danny van Leeuwen
>
> Sarah Squire
>
> Thompson Boyd
>
> Glen Marshall
>
> Salvatore D’Agostino
>
> Catherine Schulten
>
> Eve Maler
>
> Abbie Barbir
>
> Adrian Gropper
>
> Mark Russell
>
> Josh Mandel
>
> Jeff Shultz
>
> Justin Richer
>
> Tom Sullivan
>
> Elvar
>
> William Kinsley
>
> Obi Ogbanufe
>
> Corey Spears
>
> Ishmal Bartley
>
> Edmund Jay
>
> Jim Kragh
>
> Don Cameron
>
> Action Items:
>
> Eve will rewrite the “Alice Enrolls with PCP” use case to use OAuth
> language exclusively and color code it to indicate core and peripheral
> requirements.
>
> Eve (and Justin?) will brainstorm to see if they can come up with anything
> that is not captured by the planned semantic profiles.
>
> Next week:
>
> discuss and close what semantic profiling should consist of
>
> discuss and close Eve’s rewrite of the use case
>
> discuss scope structure
>
> Notes:
>
> We want to make progress on the OAuth Semantic Profile. We have three
> basic security and interoperability profiles. We have two other semantic
> profiles with FHIR-specific stuff. Do we need another bucket for things
> that don’t fit into these five profiles?
>
> For example, is identity proofing core? The fact that some proofing has
> been done is core. We just need a way to express that.
>
> What would appear in a profile? If you think about what appears in a
> technical specification, implementers have to go by imperative statements
> like “must,” “should,” “may,” or “must not.” It’s especially good when we
> can turn a “should” into a “must,” because then it becomes a testable
> assertion.
>
> Can we take this use case and build a general list of what the profile
> should contain? We have three security profiles already written, so we have
> a good start on that. However, there are interoperability nuances may be
> missing from our existing profiles.
>
> Do we need multiple semantic profiles? Do we know what they should
> contain? In this use case, we know that we have two OAuth-protected
> resources.
>
> In trying to define interoperability, should we separate interoperability
> into a phase where information moves between a server and a client and a
> phase where there is semantic understanding of the information that is
> moving between the server and the client? We aren’t talking about moving
> human-readable documents, we’re talking about moving structured data. The
> reason we split out the security profiles from the semantic profiles was so
> that we could talk to FHIR or other APIs there are a set of things you need
> to do first - those are the security profiles. We don’t have the semantic
> profiles yet.
>
> Is the role of the use cases to inform the FHIR API? Or is it something
> else? It is something else. We will be looking at how we can using the
> existing FHIR API (or not) to solve the issues presented in the use cases.
> Josh will be monitoring the working group and taking any lessons learned
> back to the FHIR project.
>
> The use case documents are here to inform the HEART project, but they are
> not a deliverable of the HEART project. The use cases represent our health
> SME’s inputs, and the interface between technical and health SMEs.
>
> If this is going to be an OAuth-only use case, we need to clarify the use
> case to use OAuth terms. Eve is willing to do that work. She will also add
> color-coding to indicate core and peripheral requirements.
>
> What do we think the FHIR OAuth semantic profile would contain? OAuth
> scopes? Anything else?
>
> OAuth scopes tied to FHIR resources.
>
> We are identifying gaps like the audience parameter. Are we going to
> include them if the root spec doesn’t include that? Perhaps we should list
> the gaps we identify?
>
> Format for identifier structure for attributes. If we are doing SSO, you
> have to negotiate the format of identifiers. With OAuth and OIDC, that
> negotiation is unnecessary. Extension claims may need to be specified. We
> don’t have a profile for extension claims in a health context.
>
> There is another working group spinning up inside OIDF also working on
> profiles.
>
> At the IETF meeting last week, the OAuth working group considered the
> notion of having an audience parameter, and it was met with general
> agreement.
>
> Adrian does not understand the meaning of “general audience profile.” The
> audience parameter takes the notion of “which resource am I trying to
> access?”
>
> Adrian is hoping that when there is a resource server with a policy about
> how it releases information that there be a way of grading, probably on a
> linear scale, its interoperability. He would like to see HEART servers have
> letter grades. Justin thinks it might be better to have a “pass” or
> “doesn’t pass” grading system.
>
> What is a semantic profile?
>
> If you look at these diagrams:
>
>
> http://openid.net/wordpress-content/uploads/2015/03/Venntechnologydecisiontree.pdf
>
> We are working with three technologies - UMA, OIDC, and OAuth. We are
> working with a health API called FHIR. We have three profiles - one based
> on each technology. We have two semantic profiles that include the FHIR API
> that can talk semantically about healthcare data.
>
> Adrian is imagining levels of patient-centricity that specify how much
> choice we give patients around what technologies they are allowed to use.
> You could think of it that way, but you have to think of it in terms of
> ecosystems. Anyone considering which profile to deploy may not be able to
> choose which technology to use - they may be limited by the technology in
> use by the ecosystem within which they are operating.
>
> A claim in OIDC is a piece of information that is attached to a user. FHIR
> attributes are attributes about a patient. However, OIDC handles login.
> FHIR should never handle login.
>
> Back-channel discussion:
>
> Casey Quinlan (to All):
>
> From the patient perspective, we (patients) are still the last group to be
> "invited in," i.e. the ecosystem is set by all other players having their
> requirements met before a person/patient is asked "how would you like to
> access your data, and certify your credentials?"
>
> Casey Quinlan (to All):
>
> IOW, I have yet to hear anything that flips the current "system sets
> security" into "patient is in control of his/her data as primary actor."
>
> Eve Maler (to All):
>
> An OAuth-based system is not patient-centric :-) - it does, however,
> preserve a patient's ability to consent to flow of data a run time,
> though...
>
> Eve Maler (to All):
>
> When we get to UMA-enabled use cases, that's when a patient moves to the
> center
>
> Eve Maler (to All):
>
> The reason OAuth is relevant as a real use case is that it's widely
> implemented, deployed, and understood (and is part of the technical basis
> of OpenID Connect and UMA!)
>
> Casey Quinlan (to All):
>
> I'm gon' sound like a simpleton, but AFAIC patient data conversations,
> which to date have not included patients/end-users in active development of
> the infrastructure/UI/UX *at all*, are almost pointless if the phrase
> "patient centric" is in use. Ain't patient centric if patient is not
> primary assigner of rights to use of said data.
>
> Eve Maler (to All):
>
> You make a good point - however, profiling use of OAuth on its own is, in
> fact, in scope...
>
> Eve Maler (to All):
>
> it's a stepping stone
>
>
> Sarah Squire
> Engage Identity
> http://engageidentity.com
>
> _______________________________________________
> 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/20150727/f0973511/attachment-0001.html>