[Openid-specs-ab] Meeting Notes (2019-07-18)

Edmund Jay ejay at mgi1.com
Fri Jul 19 21:29:47 UTC 2019


OpenID AB/Connect Call Note (2019-07-18)

Date: 2019-07-18 15:00 UTC

Location: GoToMeeting https://www3.gotomeeting.com/join/695548174

[Agenda]

1.  Roll Call
2.  Adoption of the agenda
3.  Issues
4.  AOB



[ Roll Call ]

Present: Nat, Daniel, George, Bjorn
Regret:


[Adoption of the agenda]

Identity Assurance issues


[Issues]

#1069 : Identity Assurance Section 5.1 on reason for request, 
Due to lack of people, will require further discussion


#1077 : Identity Assurance - Need Input from other JurisdictionsHave a lot of feedback from different groupsStill open because lacking input from one specific Japanese group, not sure which one
Left open as Reminder, OIDF-J should provide some comments 


1078: Identity Assurance - Incorporate EU/EC KYC Token work
Nat introduced Torsten to chair of group

1088 : register new claims in OAuth Token Introspection Response Registry
Add IANA registration section 
Send the ratified spec to IANA for registration.


1092 : Support multiple nationalities?
Not sure if needed, identity documents usually don't have 2 nationalities but people get asked these questions at border crossings
How to obtain proof? Recorded when documents are presented for verification.  
Use array to support this?Whats the purpose of the question? To establish there are multiple nationalities or yes/no question or do additional identity assurance based on response?
The purpose is to be able to respond with multiple nationalities.
The spec's purpose is to perform identity assurance with nationality as an attribute, dual nationality is just another attribute. 
Is there proof associated. As for KYC, need to produce documents for verification and is recorded in claim.
Main question is do we want array to express multiple nationalities?
If this is in response to a transaction where user could choose nationality for the transaction.If purpose is to produce identity information to an RP where RP needs to know user has proven via passport that they have dual citizen , then needs array. 
If goal is just to show identity proofed data that was chosen for  a given transaction,  then don't need array.
If there's only one then could be claim, but could also be array to allow future proofing.


1093 : Extensibility: how do we support extensibility for trust frameworks, evidence types, verification methods and id documents?
How do we setup IANA registry? 
Registry can only be created by RFCs, but values can be added to it.
Do we want to create RFC for it? 
What is the expectation on frameworks? Just going to be arbitratry? Just a string?
What level are we aiming for? 
This essentially identifies frameworks and their descriptions.
If RP is participating and IDP's framework is proven, do we need this registry at all?
If IDP publishes metadata for trust frameworks as string and there is no binding to the framework does it matter to have a registry a string?
Could have a simple doc if just trying to keep list of strings and descriptions.
Need more description of issue. 
Depends on how we want to use it.
1094 : How to treat unknown identifiers in claims parameter
If claim is essential and IDP does not understand, then should return error. 
But description does not mention anything regarding essential claims.Spec says no error is returned even if claim is essential. 
Does not explicitly mention IdP not recognizing claim. 
Up to RP to obtain claim if not returned
Is must understand what we want in this context?
Default today is to ignore, and RP is responsible for figuring out and dealing with response.Do we need a must understand flag to be added? 
Try to find Must Understand in JWx.
1097: Include Legal Persons
Might want to liaise with UMA since they've done a lot of work around legal persons.
George/Bjorn should raise question to UMALegal person issue is important and has more cost impact for financial institutions but also very difficult, 
Not sure if we want to tackle this before implementer's draft
Need to liaise with ISO TC68 also. 
Marked for post implementer's draft


1098: Add verification_score
Need more explanation of verification score : what is attached and what does it mean?


1099: Use ICAO codes for nationality and issuer country?
Needs more expertise input 
It's minor change so will accept if not objections, Daniel to create pull request


1100 ; Analyse ISO 29003
Reminder to look into ISO doc 


Next steps before implementer's draft:a) apply all agreed changes or decide to defer particular issues
b) after WG consensus, propose the foundation to start public review period


[AOB]
George waiting for Mike to post native SSO spec
Latest draft already merged in repository
George to create issue for it


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190719/38d77aeb/attachment-0001.html>


More information about the Openid-specs-ab mailing list