[Openid-specs-ab] SIOPv2 over NFC?

Mon Apr 11 08:34:04 UTC 2022

I think there are two levels to introduce NFC:

1) replace the QR Code with NFC: I’m not an NFC-expert, but I skimmed through some articles and it might be possible to let the wallet query the content of the QR code with the verifier acting as passive tag using the static handover. The rest could work the same as defined in the spec. Would that improve the security of the flow?

2) conduct the message exchange via bluetooth: that would mean the presentation could be conducted even if the user’s device does not have internet connectivity. The wallet would need to cache all necessary data (including verifier whitelist and so on), but the verifier could nevertheless have internet connectivity. Could we leverage the ISO work on mDL or do we need to invent our own protocol?

thoughts?

best regards,
Torsten. 

> Am 30.03.2022 um 22:45 schrieb Giuseppe De Marco via Openid-specs-ab <openid-specs-ab at lists.openid.net>:
> 
> 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 <mailto: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> <mailto: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 <mailto:openid-specs-ab at lists.openid.net>
>> Cc: Vladimir Dzhuvinov <vladimir at connect2id.com> <mailto: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 <mailto:Openid-specs-ab at lists.openid.net>
> https://lists.openid.net/mailman/listinfo/openid-specs-ab <https://lists.openid.net/mailman/listinfo/openid-specs-ab>
> _______________________________________________
> 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/20220411/550e17a4/attachment.html>