Burning Bridges and Breaking Brokers

Burning Bridges and Breaking Brokers

Tuesday 4I

Convener: Jim Fenton, Justin Richer, Paul Grassi

Notes-taker(s): Sarah Squire

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Because Connect.gov is built on SAML, it is extremely helpful to minimize the number of connections between IdPs and RPs. That means that a broker in the middle who everyone connects to becomes helpful. IdPs and RPs who don’t connect through the broker can talk to other IdPs and RPs through other channels, but often the ones who do go through the broker are bound by technology and policy to only talk through the broker.

OIDC makes connects between RPs and IdPs much cheaper, so that they can easily independently connect with each other. The “broker” can morph into a “trust anchor.” The trust anchor is not an authorization service. The broker normally tells you who you can talk to and who you can trust. The trust anchor can help with standardized service discovery. RPs can have local policy and get further policies about unknown IdPs from the trust anchor. The trust anchor can provide whitelists and blacklists.

An RP can use a self-contained “software statement” when it dynamically registers with an IdP showing that it has certain client attributes. The trust anchor could provide that software statement.

The US government has the idea that linking and being able to trace transactions between IdPs and RPs is bad, so they came up with the idea of using a broker so that users can’t be tracked and their activity can’t be linked.

When you start talking about accessing government services with a digital identity, you need a higher level of privacy and security. Being about to link behaviors between behaviors, institutions, or interactions is something that many American citizens object to. Building systems that engender trust and ensure anonymity is critical to getting federal agency adoption. Creating blinding mechanisms can provide a lot more trust in the system.

Depending on what service you are using, there is a wide variety of anonymity that might be possible.

In a non-brokered model, OIDC does have a per-provider identifier (PPID) mechanism that could be used in a profile. However, colluding RPs could still use the other identifying data that’s coming across the wire to track activity. To solve this problem, you can unbundle some of those attributes on a per-transaction basis.

How do we blind the IdPs about which RPs people are visiting? We shouldn’t. The IdP needs to know what RPs the users are going to for security reasons. The solution is to allow users to bring their own trusted IdP. The proofing and binding can happen outside of or in parallel to these transactions.

How does the government audit independent IdPs? graylists and trustmarks.

Why are we using IdPs? Why aren’t we just using two-party authentication? Like username and password? The problem with that is that federal agencies are not good at building those things, and it’s not tenable for users to keep track of hundreds of usernames and passwords.

How does the trust anchor help RPs trust the IdP’s assertions about important things like authentication context? RPs can send an IdP identifier through the trust anchor and the trust anchor can tell them how much an IdP is verified to be able to say - it’s a trustmark.

There’s nothing that says that we can’t have direct OIDC connections and broker connections.

Users should be able to choose IdPs like they choose email servers - they can build their own, they can pay someone they trust, or they can use a free online service. Also like email, users can have multiple identity providers.

Is this leading to a national id card? No. If I can bind a homebrew IdP to an attribute bundle that is separate from a core identity, it means I can take that with me. The government isn’t going to accept my self-asserted attributes, but there should be a mechanism to interact with a central “attribute provider,” not identity provider, and bind my homebrew IdP to that so that the attribute provider can communicate verified attributes.