[Openid-specs-igov] iGov meeting notes 2016-07-26

Sarah Squire sarah at engageidentity.com
Tue Jul 26 16:00:02 UTC 2016


Attending:

Bjorn Helm

John Bradley

Paul Grassi

Sarah Squire

Mike Varley

Mike presented on the document he’s been putting together:
openid-igov-profile.xml

It’s online here:
https://bitbucket.org/openid/igov/src/d8de3b7b6c2366fda0ca30ad4bfefdde28985f38/openid-igov-profile.xml

Is authmode necessary if we have prompt?

HEART doesn’t profile either.

Getting a profile of prompt done in the OAuth or OIDC WGs might be of
value. It’s specified in the OAuth working group, so that would make the
most sense.

It’s a security vulnerability to allow people to embed in an iframe because
it allows scraping a user’s password.

Let’s kill authmode. Let’s put together a proposed value for prompt if we
say that embedded is something we really want.

OIDC considered this, but in a pop-up window, not an iframe. But there are
issues with that in terms of mobile browsers. It’s easy to do something
custom. It’s difficult to do something consistent across systems.

There was some desire for an account chooser widget that would then have a
full page redirect.

Account chooser will be important here. That’s a javascript piece that an
RP can present to the user that allows them to see login possibilities.

We’ll change the MAY support the UserInfo endpoint to a SHOULD or a
RECOMMENDED. It’s a MUST in HEART, but we can’t do a MUST right now because
Canada doesn’t do user attributes. However, Canada might be interested in
doing it in the future in cases where the user consents to sharing.
However, UserInfo doesn’t actually require any fields other than sub, so
maybe we could make it a MUST if sub is allowed to be pseudonymous?

Do we want to try to map NIST LoA to eIDAS LoA? Do we want to go with
Vectors of Trust instead? It’s probably better to use VoT and leave it to
each country to decide how it maps to their own levels. However, let’s
leave that as a long term goal, and leave the country-specific language in
the spec for now.

Can we make it ‘highly recommended’ that you support a minimum set of
attributes? That would support maximum compatibility. Then maybe provide
guidance around using other identifiers like SSN or other government-local
identifiers.

If we specified scopes we want to support, we don’t necessarily have to
specify them. So maybe we could use something like ‘country identifier’ and
each country could treat it differently and specify how to use and protect
it?

Maybe we have a basic set and not everyone provides all of it?

Mike will add some strawman language around that so the group can have a
discussion about it.

We may also need metadata about the claim. Some people may have more than
one national ID number. John has three.

Do we combine this doc with Adam’s? Do we keep them separate? Is there a
good reason to keep them separate based on the architecture you want to
deploy?

Is there any reason we shouldn’t support discovery? It doesn’t compromise
security, and it allows for dynamic registration, so we don’t see any
reason we shouldn’t.

Mike will make edits and render the specs into HTML so we can discuss at
the next meeting.

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


More information about the Openid-specs-igov mailing list