[Openid-specs-ab] Spec Call Notes 14-Feb-19
Anthony Nadalin
tonynad at microsoft.com
Thu Feb 14 17:24:23 UTC 2019
Tom, your point has come up in ISO also, so it is a concern
From: thomasclinganjones at gmail.com <thomasclinganjones at gmail.com>
Sent: Thursday, February 14, 2019 8:57 AM
To: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
Cc: Anthony Nadalin <tonynad at microsoft.com>
Subject: RE: [Openid-specs-ab] Spec Call Notes 14-Feb-19
It was not clear from what torsten said as to the specific legal justification. Was it EU law, or just German law. As I stated before, passing data when what is required is proofing, seems to be an explicit violation of the GDPR. Unless perhaps legal necessity over-rides technical necessity.
thx ..tom
From: Anthony Nadalin via Openid-specs-ab<mailto:openid-specs-ab at lists.openid.net>
Sent: Thursday, February 14, 2019 8:51 AM
To: Artifact Binding/Connect Working Group<mailto:openid-specs-ab at lists.openid.net>
Cc: Anthony Nadalin<mailto:tonynad at microsoft.com>
Subject: Re: [Openid-specs-ab] Spec Call Notes 14-Feb-19
This has been discussed in depth at ISO as Nat knows, there are no real agreements between jurisdictions, it’s not the claims that drive the business cases it’s the provenance of the data and how the data was collected, which is outside the verifiable claims, this is the same issue that the W3C WG faces, is that a verifiable claim may mean nothing without the provenance and process
From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net>> On Behalf Of Mike Jones via Openid-specs-ab
Sent: Thursday, February 14, 2019 8:31 AM
To: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Cc: Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>>
Subject: [Openid-specs-ab] Spec Call Notes 14-Feb-19
Spec Call Notes 14-Feb-19
Brian Campbell
George Fletcher
Jeff Lombardo
Rich Levinson
Roland Hedberg
Torsten Lodderstedt
Mike Jones
Nat Sakimura
George Fletcher
Tom Jones
OpenID Connect for Identity Proofing
Torsten submitted a draft this week
[Openid-specs-ab] OpenID Connect for Identity Proofing (Proposal)
The extension can convey user data and assurance, methods, processes, and evidence
There is need for this kind of strong identity proofing
There is a need to specify which claims are verified
And to convey both verified and non-verified claims
Torsten is using this for anti money laundering, for instance
The requirements are written down in the introduction
The extension has two parts
Definition of additional claims
Such as place of birth
Syntax and semantics for requesting and providing verified claims
People are requested to review the doc by the Feb 28 call in two weeks
We will adopt it then unless objections are voiced
Nat: Minimum viable Electronic Know Your Customer (EKYC) work is being done in the EU
We should align with that work
The chair Stephane G Mouy is willing to work with us
Presentations:
https://www.dropbox.com/s/ls28l1ps53u2u2b/3.%20%20PriGroup%202%20Minimum%20Viable%20eKYC%20Framework%20Presentation%20-%20Final2%20%28002%29.pdf.pdf?dl=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dropbox.com%2Fs%2Fls28l1ps53u2u2b%2F3.%2520%2520PriGroup%25202%2520Minimum%2520Viable%2520eKYC%2520Framework%2520Presentation%2520-%2520Final2%2520%2528002%2529.pdf.pdf%3Fdl%3D0&data=02%7C01%7Ctonynad%40microsoft.com%7C8c515d7b05be4b849c0708d6929d8125%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636857602514945205&sdata=myQjnxjMjHMgigDgD%2Bl0U9ZbUNdi4sX9GgggyWpxOxE%3D&reserved=0>
https://www.dropbox.com/s/b4egx1gxma8xh9x/LoA-rated%20Attribute%20Framework%20Proposal%20-%2020181017.pdf?dl=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dropbox.com%2Fs%2Fb4egx1gxma8xh9x%2FLoA-rated%2520Attribute%2520Framework%2520Proposal%2520-%252020181017.pdf%3Fdl%3D0&data=02%7C01%7Ctonynad%40microsoft.com%7C8c515d7b05be4b849c0708d6929d8125%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636857602514945205&sdata=uuKckXm7Wc7VDDnKjiLxT2gk1ka2RO4%2BMcjETdHxb3o%3D&reserved=0>
The EKYC effort will report by the end of June to the EIDAS group in the EU
Torsten agrees that we should work with people from multiple jurisdictions
Nat: The EU plan is to have the claims provider be separate from the IdP
Torsten is using this in practice
The RP requests only the claims that it needs - in accordance with GDPR
A multi-faceted discussion of legal and regulatory requirements occurred
EU law requires that the recipient acquire specific claims about the verification
The US AAMVA, however, requires that proofing be verified but the proofing data need not be acquired
Different jurisdictions will use different procedures and legal frameworks
George: What we're largely discussing is differences in business requirements
Mike: It's up to implementers and deployers to comply with local legal and business requirements
We as spec writers should supply tools helping them do that
Nat: What we write needs to be globally relevant
Torsten: We need to collect use cases from different jurisdictions
Nat: In Japan, OIDF-J is doing EKYC work
Nat asked whether this should be in the Connect WG or another one
Mike said that the claims request and response syntax is an extension to Connect, so belongs here
We should seek broad legal and policy review as we're doing the work
Tom asked us to consider use cases in which additional information is requested outside the Connect authentication flow
Torsten: Distributed claims can be used for this
George: An attribute provider endpoint is different from the UserInfo Endpoint
Nat: We should define a mechanism for onboarding claims providers to OPs
Torsten: EIDAS imposes very specific legal requirements about verification processes and participants
Torsten particularly asks everyone to review the requirements in the introduction
We're tackling a multi-dimensional problem
Nat: This tackles one of the largest cost factors for financial institutions
Torsten: This is true of anyone going digital, such as utilities, etc.
Torsten asked if SecureKey can inform the working group of what the approach they're taking with IBM is
Jeff agreed to look into this
Federation Draft
Roland told us that in the new federation draft, Federation Operators and other participants can enforce policy
For instance, only using EC crypto rather than RSA crypto
A new policy language has been incorporated that's informed by requirements from specific use cases
Mike plans to publish the editor's draft to openid.net/specs/ draft 07 today
Open Issues
https://bitbucket.org/openid/connect/issues?status=new&status=open<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fissues%3Fstatus%3Dnew%26status%3Dopen&data=02%7C01%7Ctonynad%40microsoft.com%7C8c515d7b05be4b849c0708d6929d8125%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636857602514955198&sdata=1dFdSXTDoYRF8S6LFf14cnykCupbrYt7ibCVZo8O8Sg%3D&reserved=0>
#1029 - authentication_failed error response
Torsten wrote a proposed draft doing this
Nat requested that Torsten send an HTML attachment of the draft
We can then make an adoption decision on the call in two weeks
#1046 - Core 3.1.2.1. - id_token_hint
Torsten asks us to sanction passing an ID Token as a login_hint value
We will discuss this more on the next call
Next Call
3pm Pacific Time on Monday, February 18th
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190214/1af0ef32/attachment.html>
More information about the Openid-specs-ab
mailing list