[Openid-specs-heart] Draft Minutes of HEART Meeting 2018-02-26

Eve Maler eve.maler at forgerock.com
Tue Feb 27 05:44:15 UTC 2018


HEART 2018-02-26

Attending:

Eve Maler
Adrian Gropper
Celestin Bitjonck
Justin Richer
Nancy Lush

Justin has reorganized our BitBucket page (
https://openid.bitbucket.io/HEART/), linked from our home page (
http://openid.net/wg/heart/), to be clearer about our document drafts.
There’s a nice table there now. The Working Group Drafts column is all
live-rendered.

The latest changes are in two categories. The OAuth2 spec changes are
mostly to the FHIR (semantic) spec. The UMA spec “changes” are to both
specs, to reflect UMA 2.0 updates. (Be sure to review the diffs carefully,
especially if you’re an implementer; notes are not 100% complete.)

In the OAuth2 semantic spec, “aud” no longer points to a specific patient
record. But the client can point to a specific resource if it has it. We
may want to add some health warnings about checking RS against resource etc.

In the OAuth2 mechanical spec, the Client Types section got moved to be its
own main section, and there are a few changes within that section. The
subsection on Native Clients still requires the authorization code flow.
Both confidential and public native clients are now allowed; each requires
a unique public key, gotten through dynamic reg.

Read the new section for new PKCE details; native clients require it in
many more circumstances.

Web server clients are not allowed to be public clients.

Do we agree with using “aud” as the more generic term the way SMART does?
SMART hands over a selector and launch context. It’s a way for a client app
to signal to the AS that it knows where to get to. When not a specific
patient record, it’s a starting point. The next step is “Go talk to the
AS.” and it’s up to the AS after that.

What is the relationship of our work to SMART? Not to change SMART, but to
align our work with SMART where possible. SMART is working at being able to
be plugged in today, and HEART is a little more about what’s possible.
Those two things are starting to grow together.

What about the question of centrally managing consent, as TEFCA (for one)
has asked? The HEART group is propounding a particular solution it thinks
is straightforward, involving UMA.

The new UMA 2.0 specs started out with the UMA 1.0 spec text. They didn’t
need a lot of changes. Most of the requirements are inherited from the
OAuth2 specs. Most of the changes relate to handling tokens.

Constructs removed in UMA 2.0 were removed here (chiefly the AAT). New
constructs are mentioned and handled (chiefly the PCT); the PCT is not
required, though. The resource model hasn’t really changed; though the
syntax has changed a lot from 1 to 2, we don’t need to mention it.

The deltas are so small between the UMA1 and UMA2 versions of the profiles
that Justin essays possibly merging them somehow, if we want them both to
be extant. That’s still a live topic. An exhaustive list of UMA1-to-UMA2
changes can be found at the UMA Release Notes (
https://kantarainitiative.org/confluence/display/uma/UMA+Release+Notes).

Regarding breakfast: Eve will make a reservation for 12 at the recommended
restaurant closest to her talk location and send notice to the list.

(Partial meeting recording is here:
https://drive.google.com/file/d/17HYsReH2NHIazh3B-Aim-mGtKmH9jks4/view?usp=sharing
)


[image: ForgeRock] <https://www.forgerock.com/> *Eve Maler*
VP Innovation & Emerging Technology  |  ForgeRock
*t* (425) 345-6756  |  *e* eve.maler at forgerock.com
<firstname.lastname at forgerock.com>
*twitter* xmlgrrl  |  *web* www.forgerock.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20180226/dbc4acf8/attachment.html>


More information about the Openid-specs-heart mailing list