[Openid-specs-heart] Draft HEART Meeting Notes 2016-03-21
sarah at engageidentity.com
Mon Mar 21 20:40:19 UTC 2016
Eve did a draft Use Case:
As I announced to the list, we’re working on HEART mode for the MITREid
Connect project. It puts in a configuration switch that locks everything
down so you’re guaranteed to be compliant with the HEART specifications. I
started by going through the spec and listing out the parts that are
required, then going through the code base, and pulling that stuff out. A
lot of what I did was turn features off.
What does this apply to?
This applies to the OAuth Authorization Server and the OIDC Identity
Provider. The UMA side of things is more or less already compliant.
You’ll be seeing a much more comprehensive list of requirements as we built
out our interoperation testing work. Those tests will have a similar
structure and setup to the OIDC tests currently hosted by the OpenID
Inside of the MITREid Connect config bean, we now have a “HEART mode”. That
cascades down through various parts of the server and changes the
functionality to be compliant with the specification.
We are using a belt and suspenders approach to make absolutely sure that no
client secrets are used by any clients.
We check the redirect URIs to make sure they either have a custom scheme,
they start with https, or they start with http and are localhost. We make
sure that clients have only one of those three categories. We want to make
sure that multiple client instances aren’t registered under one
We set the default token times so that when the server is in HEART mode,
the tokens expire after the time indicated by the HEART specifications.
When HEART compliance mode is on, a small heart icon will appear in the
We will be running this against the interoperability test to find out if it
actually is compliant. This is a strict implementation which disallows
certain functionality. This system can only talk to HEART clients. It may
also be valuable to be able to talk to non-HEART clients.
Can you say more about how people like me who are focused on the use cases
and the user experience will be able to know whether this is too strict to
manage the use cases we’re concerned about?
We’ll only really know that as we begin to create pilots. I did run into a
few parts of the specification that were in error - worded to ambiguously
or strictly. I have filed those as issues. We only find out those things
after we start building things
Do we know anybody who is about to make this real in a pilot? I have the
Nosh pilot that I showed a month ago. I would love to have other people
The Nosh pilot isn’t HEART compliant.
I’m eager to come up with a set of requirements for a HEART-compliant pilot.
That’s what the specifications are. We have three technical specifications.
They list a set of technological requirements for what needs to be
available and not available for HEART-compliant software. You can build a
pilot by applying those to the pilot software. When I saw the Nosh demo, I
don’t think you were applying those.
I’m reaching out to see who else would like to work on that.
The purpose of the test harness is to test implementations against that to
give people the other half of the connection so they can try it out.
I know there are at least three implementations working on it - MITREid
Connect, ForgeRock, and Gluu. There is work going on in that area.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-heart