[OpenID-Specs-eKYC-IDA] Fwd: Identity Assurance deployment in DENIC's testbed

[Marcos Sanz]

Sorry for duplicates, I thought this might be of interest for the group.

(And if you are aware of any other implementations, don't forget to add 
them to https://bitbucket.org/openid/ekyc-ida/wiki/Implementations)

Best regards,
Marcos

-------- Mensaje reenviado --------
Asunto: Identity Assurance deployment in DENIC's testbed
Fecha: Wed, 22 Apr 2020 22:11:16 +0200
De: Marcos Sanz <sanz at denic.de>
Organización: DENIC eG
Para: technical_wg at lists.ID4me.org <technical_wg at lists.ID4me.org>

Hi all,

I am happy of making publicly available the results of DENIC's last two 
months of work in this area: our test environment supports the newest 
OIDF specification, OpenID Connect for Identity Assurance (IA) 1.0, 
fruit of the efforts of OpenID Foundation eKYC&IA working group.

The IA specification is about to finish the second public review period

https://openid.net/2020/03/24/second-public-review-period-for-openid-connect-for-identity-assurance-specification-started/

and will probably reach afterwards the status of Second Implementer's 
Draft. That being said, it is already today that we believe it has 
reached a level of maturity allowing for immediate deployment. DENIC has 
been supporting and contributing to this specification since its 
inception. We now think that the additional offer of a sandbox IdP 
service with open client registration will allow for interoperability 
tests, which will further foster the standard.

DENIC's test environment (iss = https://id.test.denic.de) allows for 
free self-registration of identifiers at https://id.test.denic.de/signup
After registration, you'll be prompted to store claims about that 
identity for test purposes. And then, any RP is ready to go and query 
them by means of the new IA standard! You can later change claim values 
(among other things) at the user dashboard: 
https://id.test.denic.de/dashboard

Please bear in mind: the IA specification deals explicitly with verified 
claims. However, and due to the nature of the testbed (which makes use 
of self-attestation, s. further up) delivered data actually undergoes no 
verification at all. Thus, these data are NOT VERIFIED and output of 
this IdP cannot be used for any production purposes whatsoever.

And finally one small technical detail: The Trust Framework parameter in 
the auth requests is currently being ignored by our test IdP. We are 
having internal discussions as to how to deal with it. We most probably 
will define a proprietary framework identifier to move on until we align 
our processes and data to a normative trust framework.

Definition of a trust framework is anyway ongoing work at the ID4me 
association and you'll soon also hear from it.

Best regards,
Marcos