[Openid-specs-igov] iGov meeting notes 2016-08-09

[Sarah Squire]

Attending:

John Bradley

Paul Grassi

Adam Cooper

Sanjay Dharwadker

Robert Faron

Justin Richer

Sarah Squire

Matt Topper

Discussion of client key requirements:

There are multiple was for the client to connect to the OP - password,
client secrets, or asymmetric keys. The client would register their public
key with the server. This is what HEART requires now as a MUST.

Do we want client keys as a requirement? Is there any reason why we
wouldn’t?

No one had objections to requiring asymmetric keys.

The key would be a jwk published at a URL. There is no need to manage keys
centrally. It’s pairwise.

People could also use certificates, but sometimes that falls down if the
bridge doesn’t respond. We can also provide documentation about how it
works when it’s published in a jwk rather than getting its trust from a
certificate chain.

Doing a self-signed X.509 cert might be easier for some deployments.

The key should be sent in its raw format in the jwk and may also be
included in a certificate as long as it’s the same key. Whoever receives it
can process the one they are most comfortable with.

Client keys for servers may be different than what we require for mobile if
mobile is in scope for this working group. We might need to use other ways
to make clients confidential. The issues for mobile clients are different.
We want to make sure we’re talking to the right instance of the client.
HEART hasn’t worked on this yet, but it’s on the docket for the next
version of the specs.

New use case:

Let’s say a user logs into the department of energy with a PIV card and
then I need to go enter my time at USDA, and I’m the first one to ever do
that, there would be a discovery and registration aspect to that, and then
the federation would grow from there.

We might be able to do it as LOA 4 with OIDC if we use token binding.

Holder of key might not be an LOA 4 requirement.

Regardless, providing man-in-the-middle protection is a good thing.

Token binding might be easier to deploy than holder of key.

Most use cases in this federation will be LOA 3 or below.

There’s a big misnomer between using a PIV and getting to LOA 4.

Discovery from a gov-to-gov federation is a good thing.

What restrictions do we need to put on discovery when it’s gov-to-citizen?

We might want a software statement on the OP validating that it is actually
government.

Given that the GSA governs all the operations in the government, that might
be a good place to issue software statements.

The relying parties would also need software statements.

Those could also come from IDESG.
It’s a use case we should work on. There are also cases where the
government is acting as an IdP to the commercial side that would also
require discovery.


Sarah Squire
Engage Identity
http://engageidentity.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-igov/attachments/20160809/5adbdb20/attachment-0001.html>