[Openid-specs-ab] SIOPv2 over NFC?

Wed Mar 30 20:45:38 UTC 2022

Hi Vladimir,
the problem I’m trying to approach is that in the absence of connectivity
it is impossible to verify the signatures and also the recognizability of a
verifier/RP.

Surely the first point is more important but also the second is not to be
underestimated in my opinion. The responsibility we are giving to users is
greater than their capabilities and a wallet should filter verifiers/rp
based on a recognition mechanism. Dangers such as phishing are an
unavoidable evil if a wallet fails to establish trust with the requesting
party. My worries are focused on the behaviour of low tech users with any
unsolicited requests by untrusted parties.

The possibility that I see for a safe recognition of a verifier/RP is to
give up, in the absence of connectivity, to dynamically establish trust and
adopt a static verification based on a proof of compliance to a trust
framework recognizable between the parties.

In OIDC Federation we have adopted trust marks that allow precisely this, a
static verification of recognition, based on a public key known and
belonging to the federation authority or its intermediary (trust mark
Issuer).

This mechanism allows us to adopt a verification of a RP even in the
absence of connectivity, because we assume that the wallet is in possession
of the public key of all trust mark issuers that can be returned within a
federation.

In the absence of connectivity, an important and necessary requirement,
surely we will have to make some compromises and I am thinking about it and
it is not easy. In OIDC Federation we have trust marks in the entity
configurations, in SIOPv2 I'm still looking for a solution. I find your
proposal of NFC extremely interesting and thank you for talking about it,
it is not at all trivial and certainly necessary

best

Il giorno mer 30 mar 2022 alle ore 16:10 Vladimir Dzhuvinov via
Openid-specs-ab <openid-specs-ab at lists.openid.net> ha scritto:

> Hi Kristina,
>
> I was thinking of SIOPv2 use in scenarios like auth, consent or credential
> presentation at physical endpoints where a protocol like NFC could fit
> nicely, and make for a more intuitive and friendly experience.
>
> The nature of a self-issued IdP is also such that internet connectivity
> for the user device is not an absolutely critical thing (whereas with a
> classic 3rd party IdP internet connectivity is a must). So SIOPv2 could
> potentially take advantage of this possibility, and support transactions
> where we have physical proximity and / or mobile network coverage is
> missing. My feeling is this could greatly enhance the appeal of SIOPv2.
> This will also allow for more robust and versatile wallet applications. The
> "classic" wallet does not require network connectivity to work, and if we
> are able to have this in SIOPv2 (where technically possible) it will be
> really nice :)
>
> Vladimir
>
> Vladimir Dzhuvinov
>
>
>
> On 29/03/2022 20:32, Kristina Yasuda wrote:
>
> Hi Vladimir,
>
> Thank you for the question! SIOPv2 over NFC has not been discussed in the
> WG before.
>
> I think it would be interesting to explore this topic. We could use
> NFC/BLE instead of QR codes to convey `request_uri` as a first step, or
> sending ID Token and VPs (and other issuer-signed credentials) over NFC/BLE
> in the response (though it will be a leap from RESTful nature of OIDC). We
> would need someone knowledgeable in NFC (and BLE?) to participate and
> contribute in the WG if we are to pursue this path.
>
> I am curious, is there an emerging use-case beyond 2.1 and 2.2 quoted
> below?
>
> Best,
>
> Kristina
>
>
>
>
>
> *From:* Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net>
> <openid-specs-ab-bounces at lists.openid.net> *On Behalf Of *Vladimir
> Dzhuvinov via Openid-specs-ab
> *Sent:* Tuesday, March 29, 2022 8:27 AM
> *To:* openid-specs-ab at lists.openid.net
> *Cc:* Vladimir Dzhuvinov <vladimir at connect2id.com>
> <vladimir at connect2id.com>
> *Subject:* [Openid-specs-ab] SIOPv2 over NFC?
>
>
>
> I wonder if there have been thoughts or considerations of the NFC protocol
> for SIOPv2 to interact with RPs?
>
> Especially given the adopted use cases 2.1 and 2.2?
>
> 2.1.
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-self-issued-v2-1_0-06.html%23section-2.1&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cf193ddebb1634ee8724608da1198b080%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637841646252107589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vlelxTSklxdpG0%2FxuJGBCRAeR3BsOQwA5wcHheoGpnk%3D&reserved=0>Resilience
> against Sudden or Planned Hosted OP Unavailability
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-self-issued-v2-1_0-06.html%23name-resilience-against-sudden-o&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cf193ddebb1634ee8724608da1198b080%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637841646252107589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=e8PLTMfOwdcq7B9zJsK9TsHsH8jdb8N1eyCC1ecOIuQ%3D&reserved=0>
>
> A hosted third-party provided OP's infrastructure may become unavailable
> or even destroyed due to natural disasters such as hurricanes, tsunamis and
> fires, or may be removed from service as a planned business decision.
> End-Users using Self-Issued OPs local to their environment, have lower
> chances of being simultaneously affected by such events.
> 2.2.
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-self-issued-v2-1_0-06.html%23section-2.2&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cf193ddebb1634ee8724608da1198b080%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637841646252157595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=r0nXzyhNgMEojyL1txVXlY1ICYZ68Pafl05H8LAoDe8%3D&reserved=0>Authentication
> at the Edge
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-self-issued-v2-1_0-06.html%23name-authentication-at-the-edge&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cf193ddebb1634ee8724608da1198b080%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637841646252157595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EpbHRZgVM62uRZDhpKdw9HSMbrCq6PL5A%2Biat5B%2FIlU%3D&reserved=0>
>
> As internet-connected smartphones have risen in availability,
> traditionally in-person interactions and services have begun to be
> optimized with digital alternatives. These services often have requirements
> for digital authentication and for other identity credentials. Self-Issued
> OPs can provide this authentication directly, without needing to delegate
> to remote, hosted OPs. This potentially allows for increased efficiency as
> well as allowing for authentication in environments which may have reduced
> connectivity.
>
>
>
> ~ Vladimir
>
> --
>
> Vladimir Dzhuvinov
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220330/91093766/attachment.html>