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

John Moehrke johnmoehrke at gmail.com
Mon May 23 23:50:23 UTC 2016


Let me correct a misunderstanding. IHE does not require mutual with TLS in
cases where OAuth is used. It actually discourages it as it for the reasons
you gave, and more.. Specifically because OAuth covers the same risk space
and does it better.

John
On May 23, 2016 3:59 PM, "Sarah Squire" <sarah at engageidentity.com> wrote:

> 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
>
> _______________________________________________
> 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/20160523/319fbdab/attachment.html>


More information about the Openid-specs-heart mailing list