Attending:

Debbie Bucci

Catherine Schulten

Sarah Squire

Tom Sullivan

Adrian Gropper

Luis Maas

Thompson Boyd

Justin Richer

Cait Ryan

Nancy Lush

Glen Marshall

Edmund Jay

Kathleen Connor

Dale Moberg

Jim Kragh

Regrets:

Eve Maler

Discussion

Eve did a draft Use Case: https://docs.google.com/document/d/1Y-LA9S3HcSBmQCPAVZjaesfowXjkHC5vHtQ-yBQiPN0/edit

Justin 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.

Adrian What does this apply to?

Justin 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 Foundation

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 registration.

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 footer.

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.

Adrian 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?

Justin 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

Adrian 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 making pilots.

Justin The Nosh pilot isn’t HEART compliant.

Adrian I’m eager to come up with a set of requirements for a HEART-compliant pilot.

Justin 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.

Adrian I’m reaching out to see who else would like to work on that.

Justin 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.

Debbie I know there are at least three implementations working on it - MITREid Connect, ForgeRock, and Gluu. There is work going on in that area.