[Openid-specs-heart] Draft HEART Meeting Notes 2016-05-23

[Sarah Squire]

Attending:

Debbie Bucci

Kathleen Connor

Sarah Squire

Thompson Boyd

Glen Marshall

Luis Maas

Justin Richer

Cait Ryan

Jin

Justin:

Mike Jones reviewed the HEART specification. We’ll start with “what to name
stuff”. OpenID Connect used “basic” and “implicit” for their flows. We
wanted to be clear that different kinds of clients need to use different
kinds of flows.

“id_token code” response type would be unusual in a HEART system.

We need to add some clarification around key generation and management.

Debbie:

So, the ones we agree on you’ll change, and the ones we need to discuss,
you’ll open issues for?

Justin:

Yes. Some of the things in Mike’s feedback are great, but some of them we
need to discuss.

We want to discourage people from using the implicit flow unless they have
an in-browser client.

We have use cases that don’t involve end-users like bulk transfers and data
syncing.

The paragraph on mutual TLS never got fully baked, and it would be hard to
implement, so I’m fine with striking that paragraph.

Glen:

In IHE, mutual TLS is required when you’re exiting the domain. But other
methods can substitute for it.

Justin:

As soon as you have multiple CAs and access rights, it becomes somewhat
unwieldy. I think it’s a mistake for IHE to require it. I’m leaning toward
being quiet about it.

Debbie:

GreenButton is also using mutual TLS for certain service access.

Justin:

We’re already using signed JWT assertions. If we wanted to support this, we
would want to have a definition of oauth client authentication using a TLS
cert, which hasn’t been formalized by anybody.

We are making some significant departures from how things are now in terms
of dynamic registration. This allows consumers to use a client of their
choice.

We could use better text around software statements. We as a working group
need to decide how much detail we want to go into?

Debbie:

Do we have a timeline for these updates? I’d like to get them done before
September.

Justin:

Then we’d have to have that discussion and let the use cases take a back
seat for a while.

Glen:

I think we should leave software statements in. They become important when
you have to do a deep level of software inspection.

Justin:

Yeah, we think they’re useful, and they come out of BlueButton originally.

We want to talk about some of the user experience. We want the AS to tell
the user that a peice of software was vetted by a trusted third party. We
do need to improve this language. We want to encourage it as best practice,
but not mandate it.

We need to point out that a single piece of software can have multiple
client ids with the same AS.

Glen:

We need to keep in mind that if we make things optional, an AS may have to
accommodate all of them.

Justin:

The Microsoft implementation issues JWTs that are keyed to specific
servers. For more on that, see the thread on the list. For those
implementations, introspection is really hard. But we want to have
introspection in HEART. Introspection isn’t necessary with OIDC, because
you’re only protecting one resource.

Same idea with revocation. We want OAuth clients to be able to say “I’m not
using this token anymore.” We would also like to tell the AS “if you can
throw out the token, then do it”

We want to give good guidance on key caching.

Debbie:

Is there a difference about audience between HEART and SMART?

Justin:

There it’s a launch context. Here it’s a record indicator.

For an authentication event, five minutes seems like a long time, but this
is only guidance.

We need to justify why clients might want a higher security level. It’s
required for an AS to support, not a client. That was the intent.

The basic idea of the conformance section is that if you have an OIDC HEART
IdP, it needs to be able to talk to a HEART RP. However, it doesn’t
necessarily have to be a HEART AS.

Sarah Squire
Engage Identity
http://engageidentity.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160523/ede01462/attachment.html>