Hi Roman and Torsten,
This is a reply to the mail sent today by Torsten on the OAuth mailing
list where I modified the name of the thread to add ": a societal choice".
I also send a blind copy to the SPICE BoF.
Lest us go away from nails and screws and take a higher view, e.g.,
using an air balloon.
The series of documents produced by the OAuth WG took its origin with
the RO-AS relationships and of the AS-RS relationships.
At this time, unlinkability was not a concern.
Now the model is attempting to be extended to a different use case, but
still using the same architecture which *by design*
is unable to support the unlinkability property between verifiers. This
is where a red line has been crossed.
A concern is that this architecture is currently considered by the EU in
the context of the EUID wallet.
The ARF (Architecture Reference Framework) - Outline was stating on page
18:
"The EUDI Wallet SHALL enable the user to share only the information
they intend to share".
Source: European Digital Identity Architecture and Reference
Framework – Outline - 22 February 2022
In the ARF version 1.1.0 (20 April 2023) that sentence has been sneaked
out.
In clause 1.4. Objective(s) of the COM(2021) 281 final 2021/0136 (COD)
Proposal for a REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL
amending Regulation (EU) No 910/2014 as regards establishing a framework
for a European Digital Identity, the text states on page 45:
A strengthened *privacy-by-design approach* could yield additional
benefits since the wallet would not require intermediaries in the
process of asserting the attributes,
thus enabling the citizen to communicate directly with the service
and credential providers. The increased data security of the wallet
would prevent identity theft,
thus preventing financial loss to European citizens and businesses.
A *privacy-by-design approach* means that privacy shall considered at
the time of the design (I would even say *before* the design) and not
*after* the design.
A system that does not follow a privacy-by-design approach is very
unlikely able to be able to accommodate afterwards privacy considerations.
A "privacy-after-design" approach usually does not work.
A press release from June, 3, 2021 was making a citation of some
statements from Margrethe Vestager, Executive Vice-President for a
Europe Fit for the Digital Age.
See: https://ec.europa.eu/commission/presscorner/detail/en/ip_21_2663
"So that we will decide how much information we wish to share about
ourselves, with whom and for what purpose".
Unfortunately, if the following documents are transformed into RFC s by
the IETF and adopted by the EU:
* draft-ietf-oauth-attestation-based-client-auth
* draft-ietf-oauth-sd-jwt-vc
* draft-looker-oauth-jwt-cwt-status-list
this statement will not be true any more.
It is important to remember that eIDAS 1.0 was originally only targeted
for the public sector within Europe.
eIDAS 2.0 is now targeted for both the public and the private sector.
While a linkability property was acceptable for the public sector,
is it also acceptable for the private sector ?
Using ARF v1.1.0, every EU citizen will be traceable by *any Resource
Server around the world*.
Is it advertised in the ARF v1.1.0 document ? Everybody already knows
the answer ... which is negative.
The ARF v1.1.0 document only contains a single occurrence of the word
"privacy" !
The draft-looker-oauth-jwt-cwt-status-list is yet-another-draft that
does not allow to support the Unlinkability property between verifiers.
It is however possible to address the concern of revocation or
suspension of a Credential using an architecture rather different
from the one developed in the OAuth WG.
Should EU citizens only have the following two choices:
1) use a solution that allows any Resource Server around the world
to be able to link their users, or
2) don't use that solution at all, if they don't want Resource
Servers around the world to be able to link their users.
Of course, for making a wise choice, end-users should be informed about
the problem and, at this time, they aren't.
Torsten wrote: "while working with the eIDAS expert group". It would be
worthwhile if Torsten would be able to inform
the eIDAS expert group about this issue and report its feedback.
It is possible to develop a solution that prevents any Resource Server
around the world to be able to link their users.
In case, the linkability property between verifiers is desirable for
some usages, it will be easy to add a claim that allows to support
the linkability property, while the reverse is untrue.
A third choice should be offered:
3) use a solution that prevents any Resource Server around the world
to link their users, if the user wishes so.
This is not simply a technical choice but a *societal choice*.
Should the IETF contribute to a single solution that, by design, is
unable to support the Unlinkability property between verifiers
and is not extensible to support the Unlinkability property between
verifiers ?
Should two different and incompatible models be developed by the IETF ?
Denis
PS. "The Commission is already investing €46 million from the Digital
Europe Programme in four large-scale pilots, to test the EU Digital
Identity Wallet
in a range of everyday use-cases, including the Mobile Driving Licence,
eHealth, payments, and education and professional qualifications".
Press release. 29 June 2023. Source:
https://ec.europa.eu/commission/presscorner/detail/en/ip_23_3556
Hi Roman,
I’m writing this post on behalf of the group of co-authors who
proposed the following drafts for adoption by the OAuth WG:
draft-ietf-oauth-attestation-based-client-auth
draft-ietf-oauth-sd-jwt-vc
draft-looker-oauth-jwt-cwt-status-list
We have brought these drafts to the IETF because they are built on
IETF drafts/standards and enhance them. Those drafts are interrelated
and part of a bigger effort to provide initiatives around the globe
for building ecosystems based on the Issuer/Holder/Verifier model,
especially focussing on EU’s eIDAS, with interoperable technical
standards.
The work is based on two pillars, Selective Disclosure JWT (SD-JWT)
and OpenID for Verifiable Credentials (OID4VC). The latter is a
credential format agnostic family of protocols for issuing and
presenting verifiable credentials and authenticating users based on
keys in the wallet. These specifications are being standardized at the
OpenID Foundation; they are already referenced by the eIDAS
Architecture and Reference Framework.
SD-JWT and OID4VC are combined in a specification designated as
“OpenID for Verifiable Credentials High Assurance Interoperability
Profile with SD-JWT VC” (HAIP). HAIP instantiates OID4VC with the
credential format SD-JWT VC to allow implementers to build truly
interoperable systems. This is the contribution we intend to make to
eIDAS.
While working on HAIP we identified missing pieces in the overall
picture, most notably a way to use well-established JWT content rules
and its extensibility model as basis for representing Verifiable
Credentials with JSON payload. That’s why we drafted
draft-ietf-oauth-sd-jwt-vc.
We also noticed Verifiable Credentials are typically long living
credentials and thus need a way for its issuer to influence its
status. That’s why we drafted draft-looker-oauth-jwt-cwt-status-list
and incorporated it into draft-ietf-oauth-sd-jwt-vc.
In addition, we learned while working with the eIDAS expert group and
others that wallet to issuer authentication needs to fulfill very
special requirements. That’s why we drafted
draft-ietf-oauth-attestation-based-client-auth as a new client
authentication method.
To sum up, draft-ietf-oauth-sd-jwt-vc and
draft-looker-oauth-jwt-cwt-status-list extend the work being done
around SD-JWT so we feel the OAuth WG is the best place to evolved
them. However, we are open to discuss to carve out the work around
credential formats and supporting mechanisms into a new working group.
draft-ietf-oauth-attestation-based-client-auth is an OAuth extension,
so we believe it belongs to the OAuth WG.
** What's the body of work around SD/JWT/VC that should be done and
how much work will that be? What needs to be done first?
draft-ietf-oauth-sd-jwt-vc and draft-looker-oauth-jwt-cwt-status-list
are fundamental building blocks on the level of credential formats for
building applications according to the Issuer/Holder/Verifier model. A
lot of initiatives around the globe are looking for technical
standards for this kind of application now. (For example, the eIDAS
expert group hopes to finalize its Architectural Reference Framework
(ARF) this year.) So there is a window of opportunity for IETF and
this group to make an impact with solid, secure and usable technical
standards.
We don’t plan further contributions in this space to the WG beyond the
proposed drafts.
** What unknown about the direction and needed tasks?
I hope I could shed some light on our plans.
** For whatever that work might be, how should the OAuth charter
evolve to support the work?
We suggest extending the charter to cover work on credential formats
and related mechanisms based on JWTs. As already mentioned above, we
are also open to moving this work into a new dedicated working group
once such a working group is operational. That working group might be
established as a result of the SPICE effort. It would be good to
coordinate closely with those developing CBOR-based credentials to
keep that work and ours architecturally aligned. We, however, see the
need to keep working on the drafts to meet the expectations of current
and prospect implementers.
** Is there work to be done around bridging the architectural
narrative used in the core OAuth framework/RFC6749 (AS, RS, RO) and
three part model (issuer, holder, verifier) used in
draft-ietf-oauth-selective-disclosure-jwt?
We suggest clearly distinguishing protocol aspects from data format
aspects. draft-ietf-oauth-selective-disclosure-jwt as part of the
credential format aspect has dependencies on JWT but no dependencies
on RFC 6749.
There is work to be done to cater for protocols sitting on top of
OAuth for supporting the issuer/holder/verifier model. OpenID4VC is
built on top of OAuth and we have come up with some observations
around that. For example, clients (either verifiers or wallets acting
as clients towards issuers) are typically not managed by the AS.
Either there is a 3rd party that the AS relies on for that purpose, or
the client starts interacting without any pre-established
relationship. Also, in a wallet world, we see the need to allow an app
on the phone to securely authenticate towards an AS, which requires
key bound assertions. draft-ietf-oauth-attestation-based-client-auth
is our proposal to cope with those issues.
best regards,
Torsten.
Am 8. Sept. 2023, 21:07 +0200 schrieb Roman Danyliw <r...@cert.org>:
Hi!
We've observed growing energy around JWT, selective disclosure and VC
related topics in the WG in recent meetings. We spent almost all of
the third OAuth meeting at IETF 117 on related topics. The initial
SD-JWT (draft-ietf-oauth-selective-disclosure-jwt) has been followed
up with SD-JWT-VC (draft-ietf-oauth-sd-jwt-vc). There is also work
like draft-looker-oauth-jwt-cwt-status-list being proposed.
As promised at IETF 117, we would like to start a conversation about
the direction the WG would like to take at a strategic level rather
than continuing to deal this topic in one document increments of
additional scope.
** What's the body of work around SD/JWT/VC that should be done and
how much work will that be? What needs to be done first? What unknown
about the direction and needed tasks?
** For whatever that work might be, how should the OAuth charter
evolve to support the work?
** Is there work to be done around bridging the architectural
narrative used in the core OAuth framework/RFC6749 (AS, RS, RO) and
three part model (issuer, holder, verifier) used in
draft-ietf-oauth-selective-disclosure-jwt?
Thanks,
Roman, Hannes, and Rifaat
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
