Self ID

Session Topic: Self ID: What technical problems or incentives do we need to make hosting your own IDP really a viable thing?

Wednesday 3G

Convener: Bryant Cutler

Notes-taker(s): Matthew Schutte

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

Topic Altered during session to Self-Authentication, then to Distributed-Authentication

GOAL: What can we do to make sure that RPs begin to accept authentication from more than just the big monoliths (Google, FB, Twitter etc.)

Why do relying parties feel tentative about accepting Self ID

1) User Experience

• a. Liability / Risk (perceived by the management)
• b. Nascar > empty text input
• c. Quality of Authentication experience (if you use twitter or FB, they don’t mess up the flow) if you are letting everybody choose how to authorize, the diversity of quality in their auth processes may result in greater friction.
• d. Patch / Security
  • i. Customer who fails to adequately maintain their blog – do you go after them because their negligence led to the fraud (that they were a victim of)?
• e. Resourcing
• f. DNS ponage
  • i. Belief that connecting to arbitrary sites opens us up to DNS spoofing etc..
• g. Size / Trustworthiness of provider
• h. Assurance levels provided by IDP

Question:

Why do we think Self ID is important?

Personal sovereignty v. corporate serfdom

As we see new authentication mechanisms emerge – support for (not necessarily personal ID provider) but arbitrary identity provider. Wants to open up the market to encourage the innovation in the authentication / security space.

How do you prevent the assertion of false identity?

objection: authentication is different from identity. What is a false identity?

Separating Authentication and Identity.

There is disagreement about where authentication occurs. Some in room contend that it occurs at the beginning of sign up. Others argue that it only occurs after enrollment.

Authentication deals with an identifier that we use for both enrollment and authentication.

What we are trying to talk about:

Enrollment and authentication

What we are not trying to talk about:

How we handle payment etc.

The vast majority of people choose to use

We are ok with allowing people to host their own email server or their own dns server (RP’s end up interacting with them freely despite the potential problems that could occur there). Why are RPs not OK with us using our own authentication server.

There was a bit of a discussion

Why can’t I show up with a Bank as my authentication service.

With and ID

Can authenticate with AWS

Can browse otherwise public info

May be able to bookmark for use later

• i.e. you will only use that ID to make use of a service in ways that

you enable pseudonomous use – it would be better if we started from that place. We don’t want it bound to an identity up front. L

we are breaking the person away from those moments of administration.

Why do I need to enter into an administrative relationship until I chose to. At those moments where an administrative relationship is required, then I can up the ante.

Ex: browsing anonymously, for posting, we may require some authentication, for purchase we would go beyond that – going into identity etc.

Q: What is the difference between AWS SAML and OpenID processes.

Step 1: open account

Step 2:

Enrollment happens before there is value. As a result, trust is not a problem at that point.

Assurance of the IDP vs Assurance of the accounts that the IDP gives you.

Level of Assurance – even with Google, you are at best at LOA 1, not LOA 2, because they are not verifying their identity with physical https://www.cio.wisc.edu/security-initiatives-levels.aspx

Indieweb guys want to let people log into a wiki.

IndieAuth They ask you to put rel:me link in your website that points to your twitter id. They go through your domain name to discover who you are willing to use to log in with. By doing that, they allow you to repudiate FB or Google if you decide you don’t trust them.

It doesn’t boil the ocean, does make use of those existing services.

One participant’s goal: To be able to repudiate a service

How do you get developers to adopt any API’s?

The reason developers are using social authentication rather than SAML – Google and other auth providers did a very good job of listening to developer concerns and created something that was useful to developers.

OpenId Connect is useful is because it is the API is useful

The issue is that “The business model affects the nature of interaction.”

I’m a credit union that is highly respected for their protection of users.

Banks need a high level of assurance – they have ten different ways of authenticating – are not going to outsource that to anyone.

Needs to be user friendly both for developers AND for end users.

==

NASCAR remains a better user experience than an empty text input

Account Chooser – local storage that will enable us to show up at a page, have the auth providers populate on the page

==

I get better security because I’m not storing account credentials

Loss of control of account reset is problematic for the RP.

No consequences

We need a ZERO additional effort w/ implementation, demonstrate customer benefit,

Fix account chooser, lower the cost of the implementation.