Regards and Best Wishes
Jaimandeep Singh
On Thu, Aug 4, 2022 at 9:17 PM David Chadwick
<[email protected]> wrote:
Answers inline below
On 03/08/2022 14:57, Torsten Lodderstedt wrote:
Am 02.08.2022 um 19:30 schrieb David Chadwick
<[email protected]>
<mailto:[email protected]>:
Hi Torsten
your use case sounds like an online use case, not an offline
one. So its a question of balancing a long lived SD-JWT along
with a revocation mechanism vs a short lived minimal JWT
containing just the claims that are needed.
That’s correct.
I thought that SAML, OAuth2 and OIDC had opted for short lived
non-revocable claims rather than long lived revocable ones due
to the experiences of using revocation with X.509 PKCs.
SAML and OIDC are considerably simple, flexible, and secure
solutions to the challenges of selective disclosure, direct
identifiers, and current claim values.
However they tend to support maximum privileges/attribute release
rather than minimum privileges because they are provided at user
login, before the RP knows what the user wants to do. So often
more user PII than is required is released. OIDC4VPs allows us to
solve this with SD and incremental releases of claims as the user
progressively request to do more sensitive transactions. (By the
way this is what we implemented in a non-standard way prior to the
W3C VC DM being published. It is documented in the IEEE Comms
Standard, viz:
David W Chadwick, Romain Laborde, Arnaud Oglaza, Remi Venant,
Samer Wazan, Manreet Nijjar “Improved Identity Management with
Verifiable Credentials and FIDO”. IEEE Communications Standards
Magazine. Vol 3, Issue 4, Dec 2019, Pages 14-20)
They are an excellent solution for Web SSO. However, they require
the IDP to be always on, an online connection to the RP, and
share a lot of metadata with the IDP.
I would think that always online is not an issue in today's
interconnected world. Rather users expect everything to online
24/24 as do businesses. I suspect any service that is not online
24/24 is the odd one out and disliked by most people. Plus the
revocation service has to online 24/24
X.509 certificate never had those problems, but are inflexible
and require revocation. Verifiable Credentials to me are more
like X.509 certs but with more flexibility, simpler to use data
formats, and the option to selectively disclose claims.
So the question merely is what parameters to optimize for.
Agreed, its all about making choices and balancing security,
privacy, usability and trust
The current thinking I perceive is to give users long lived
credentials, which means the issuer doesn’t need to be always on,
there is no need for online connection, and the issuer does not
get any metadata on when, what kind of claims is being used. This
also makes offline use of such credentials an obvious option.
Which essentially boils down to short lived unrevocable vs. long
lived revocable. The mDL solution of a relatively long lived
credentials without revocation might be OK for a driving license
that changes infrequently. But this is not a model that will
satisfy all verifiable credentials. Also mDL does mean that the
IDP will need to be almost always online for users to refresh
their credentials when they have expired.
In a way you are swapping the IDP being always on, to the
revocation service being always on and an IDP that is periodically
on to update it. The problem we have seen with this approach in
the X.509 world, is that if the revocation service is not
available, browsers have switched from a hard fail (which the
standard mandates) to a soft fail so that the users can continue
working, which leads to an obvious vulnerability of using a
revoked certificate. If the IDP is not on, then a hard fail is
inevitable with OIDC, and users will soon require the service to
resume again so that they can get back to work. So the latter is
more secure though less usable (which X.509 used to support with
its hard fail). I suspect that in some use cases (maybe financial
ones?) hard fails are preferable to soft fails?
However, the lifecycle of such credentials needs to be managed. I
think revocation lists are an ok solution to that problem. I
don’t see how the issuer could learn where a credential is being
used with revocation lists as the verifier will just download the
whole list for evaluation and revocation lists typically do not
authenticate the verifier. Which leaves the IP address of the
verifier as metadata without any further context.
True, a well designed revocation scheme leaks less information to
the IDP.
I think the issuer part of it is more complex than people
currently believe since issuers need to maintain a list of the
credentials they issued (not needed in OIDC). Updates to
credential data need to be published and last but not least,
there needs to be away to let credentials be revoked. E.g. an
user or a wallet provider might need to ask an issuer to revoke a
certain credential because of abuse.
Does this not imply that the IDP has to always on for the user to
report a problem??? Which was something you wanted to escape from.
That’s gone be though.
Seems like the above was a typo.
That might be the reason why ISO mDL uses expiration (I guess
weeks to month) instead of revocation. And the wheel starts to
turn again …
Exactly. Because there is no perfect solution, but only one that
compromises one feature for another. So in the end if the users
decide which is preferrable, it will mean that usability wins and
trumps security and privacy concerns!! If service providers decide
they may opt for hard fails with security and privacy trumping
usability.
Which brings me to the conclusion that long lived one-time use VCs
with soft revocation (i.e. continue as if everything is OK if
revocation info is not available) with blinded property names and
values is the best compromise from a usability perspective i.e.
one time use privacy enhanced SD-JWTs. I wonder how many wallets
can currently handle this? I guess zero at the moment, but its an
objective worth aiming for. Alternatively short lived one-time use
VCs with no revocation, that are issued periodically or on demand
(dependent upon the validity period) is the best option from a
security and privacy perspective. If the IDP is not available the
user will not be able to do any work once his stock of short lived
credentials are exhausted.
Do you agree?
Kind regards
David
Kind regards
David
On 02/08/2022 10:47, Torsten Lodderstedt wrote:
Am 02.08.2022 um 11:06 schrieb Warren Parad <[email protected]>:
I was following your train of thought, let me paste that here
for transparency, you specifically said:
In an OAuth scenario, the user‘s wallet would act as AS
and issue access tokens (those could be short lived) that
effectively are verifiable presentations (based on a
verifiable credential) audience restricted for a certain
RS. The client wouldn’t even know it’s a verifiable
presentation since the access token is opaque to the client.
Which I replied:
If the user's wallet acts as the AS issuing tokens, then
there is zero need for this draft because we could pass
the *scopes* that relate to the claims directly to the AS,
and have the AS return a limited JWT, and we would
actually do that every time because:
1. we can
2. because the tokens have short lifetime
So that isn't a valid argument, unless there's a reason
why the AS wouldn't be able to do this.
In this conversation, I'm still not able to parse what you are
saying. Yes, of course the user having a physical device (as
the AS) to issue tokens is privacy enhancing, but then we
don't need this draft as I just proved. Or are you talking
about a different point?
In the model I envision, OAuth clients are able to obtain
access tokens for the user’s services through the user’s
wallet. Since the wallet is not the AS the RS trusts, I would
like to utilize verifiable credentials as basis for issuing
access tokens from the wallet. That means the credential is
issued by the AS and the wallet can mint access tokens
containing a presentation of such a credential. From a RSs
standpoint this retains the standard trust model since the RS
only accepts access tokens containing a credential from an AS
it trusts.
I also assume that a single AS is managing access to several
RSs as that was the case in almost all deployments I was
involved with.
I think the most efficient and flexible way to implement this
scenario is to issue a single SD-JWT based credential and to
mint RS-specific access token as needed by using SD-JWT’s
selective disclosure capabilities. So an access token for the
user’s contacts API would only include the claims needed for
this service (e.g. the privilege to use the service) whereas an
access token for the streaming API would include the data
needed there (e.g. authorised channel lists and so on).
On Tue, Aug 2, 2022 at 10:54 AM Torsten Lodderstedt
<[email protected]> wrote:
Am 02.08.2022 um 10:48 schrieb Warren Parad
<[email protected]>:
Can you please reread what you wrote and rephrase it
differently? Telling us to look at the OAuth JWT RFC
isn't helpful here.
You say the AS can issue an access token every time and I
say the wallet can issue access tokens on its own without
the need to go back to the AS every time again. That’s
privacy enhancing and helps scalability.
Also it isn't clear which part of your statement you are
trying to clarify. What does "original AS" mean? Are you
suggesting a "multi AS" configuration? What does that
look like?
On Tue, Aug 2, 2022 at 10:44 AM Torsten Lodderstedt
<[email protected]> wrote:
Am 02.08.2022 um 10:35 schrieb Warren Parad
<[email protected]>:
Why would we not include those seemingly critical
details in the draft then?
1. Let's define what a *verifiable presentation *is
(is that already defined somewhere? I didn't see
it in the draft)
2. Require the JWTs to be signed with a private key
from a certificate chain, and include the whole
certificate chain in the body. (I don't think
there is already a RFC for this, but I could be
wrong)
Let's also talk about this comment:
In an OAuth scenario, the user‘s wallet would
act as AS and issue access tokens (those could
be short lived) that effectively are verifiable
presentations (based on a verifiable credential)
audience restricted for a certain RS. The client
wouldn’t even know it’s a verifiable
presentation since the access token is opaque to
the client.
If the user's wallet acts as the AS issuing tokens,
then there is zero need for this draft because we
could pass the *scopes* that relate to the claims
directly to the AS, and have the AS return a limited
JWT, and we would actually do that every time because:
1. we can
2. because the tokens have short lifetime
So that isn't a valid argument, unless there's a
reason why the AS wouldn't be able to do this.
Well, how many access tokens have you seen in the
wild that only contain an access token? I haven’t,
any of the carriers some for of user claims, e.g. a
sub, in most cases some privileges/roles. Please take
a look at
https://www.rfc-editor.org/rfc/rfc9068.html for best
current practice.
Using a VC in the way I described means the original
AS doesn’t need to be involved in the
On Tue, Aug 2, 2022 at 10:14 AM Torsten Lodderstedt
<[email protected]> wrote:
Am 02.08.2022 um 09:53 schrieb Warren Parad
<[email protected]>:
If we are in a offline scenario how does the
verifier got ahold of the public key associated
with the id token?
Why id token? I would assume we are talking
about verifiable presentations, right?
There are a couple of ways to provide the
verifier with the public key needed to verify.
The (raw) key could be contained in the
credential or the presentation. If a trust chain
is required, a x.509 certificate could serve the
same purpose.
Beside that offline has different facets. In a
Point of Sales scenario, even though the wallet
would be offline the checkout counter would most
likely have connectivity. That would also allow
to resolve the public key on demand.
They would need to be online, that defeats any
benefit this could provide.
Or what if the token you have expires. Many
providers issue tokens only good for 1 hour. If
that expires, the user has to go through the
online flow again.
Unless we can add some provisions to ensure
long lived token validity, I think in practice
we're cripling the usefulness.
Absolutely. That’s the reason a verifiable
credential has a much longer lifetime simply
because the user should be able to use it in a
sensible way. As this makes replay more likely,
all verifiable credentials formats utilize
holder binding for reply detection. The public
key mentioned above is part of the cryptographic
holder binding that only the legitimate user is
able to execute.
In an OAuth scenario, the user‘s wallet would
act as AS and issue access tokens (those could
be short lived) that effectively are verifiable
presentations (based on a verifiable credential)
audience restricted for a certain RS. The client
wouldn’t even know it’s a verifiable
presentation since the access token is opaque to
the client.
On Tue, Aug 2, 2022, 04:21 Kristina Yasuda
<[email protected]>
wrote:
I support adoption.
To add some color.
One of the use-cases is a flow where
issuance of a user credential (collection
of user claims) is decoupled from
presentation (where both issuance and
presentation of a user credential are done
using extensions of OAuth flows). The goal
of this decoupling is to avoid “issuer call
home”, where the user can send a user
credential directly to the RP, without RP
needing to contact the Issuer directly. So
the motivations are not limited to offline
scenarios, but are applicable to the
scenarios that want to recreate in the
online environment, the user experience of
presenting credentials in-person.
Driver’s Licence just happens to be an
example familiar to many, and there is no
reason it cannot be a diploma, or an
employee card, or a training certificate,
etc. But it is worth highlighting that
SD-JWT work becomes critical if we are to
enable ISO-compliant mobile Driver Licences
expressed in JSON to enable online
scenarios and make life of the Web
developers easier (as opposed processing
data encoded as CBOR and signed as a COSE
message). Selective disclosure is a
requirement in many government issued
credentials, while the usage of advanced
cryptography is not always encouraged by
the national cybersecurity agencies.
Regarding an approach where issuer issues
multiple JWTs of a same type but with
different subset of claims, it is not an
ideal way to do selective disclosure with
JWTs (type as a way to differentiate
credential with one data structure/syntax
from another). It complicates
implementations that try to provide RP-U
unlinkability (RPs cannot collude to track
the user). The simplest way to achieve
unlinkability with JWTs without using
advanced cryptography is to issue multiple
credentials of the same type but with
varying use identifiers and enable pairwise
identifiers per RP. Now there are multiple
copies of each JWT with subset of claims of
the same type. This greatly complicates
presentation of these credentials too –
since credentials are of the same type, now
wallet needs to manage the combination of a
subset of claims + pairwise identifier…
What if the implementation also wants
predicates property, where age_over_XX
boolean is sent instead of a birthdate
string? The simplest way to do predicates
with JWTs without using advanced
cryptography is to have issuers to issue
multiple age_over_xx booleans so that an
appropriate one can be selectively
disclosed to the RP. How many “JWTs with
subset of claims” does the issuer needs to
issue to account for all possible age
requirements? Note that it’s not just
age_over_21 to start gambling, it’s also
age_over_65 to get pension benefits.
Managing the combinatorial explosion of
sets of claims in speculatively issued
JWTs, many of which will never be used,
seems unwieldy, to say the least. "A
conventional JWT with a subset of claims"
approach could be taken in some
implementations, but it should not prevent
a simpler, extensible alternative of SD-JWT.
Finally, as Giuseppe pointed out, an option
to blind claim names is on the table. As
discussed on this list previously, we
should analyze privacy properties of the
mechanism and decide if we want to mandate
it – which can be discussed after the adoption.
Best,
Kristina
*From:* OAuth <[email protected]> *On
Behalf Of * Rifaat Shekh-Yusef
*Sent:* Thursday, July 28, 2022 8:17 PM
*To:* oauth <[email protected]>
*Subject:* [OAUTH-WG] Call for adoption -
SD-JWT
All,
This is a call for adoption for the
*SD-JWT*document
https://datatracker.ietf.org/doc/draft-fett-oauth-selective-disclosure-jwt/
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-fett-oauth-selective-disclosure-jwt%2F&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Ca2d72420ea2c40f2d7c908da70f7b388%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637946506426392735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=d1EoHuRcBi40%2B1h1p5yZ28O7l8oq%2FibDewlJObT1Gwc%3D&reserved=0>
Please, provide your feedback on the
mailing list by *August 12th*.
Regards,
Rifaat & Hannes
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
