<div dir="ltr">Hi Vladimir,<br>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.<br><br>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.<br><br>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.<br><br>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).<br><br>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.<br><br>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<br><br>best</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno mer 30 mar 2022 alle ore 16:10 Vladimir Dzhuvinov via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi Kristina,</p>
<p>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.<br>
</p>
<p>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 :)<br>
</p>
<p>Vladimir<br>
</p>
<pre cols="72">Vladimir Dzhuvinov</pre>
<div><br>
</div>
<div><br>
</div>
<div>On 29/03/2022 20:32, Kristina Yasuda
wrote:<br>
</div>
<blockquote type="cite">
<div>
<p class="MsoNormal">Hi Vladimir,<u></u><u></u></p>
<p class="MsoNormal">Thank you for the question! SIOPv2 over NFC
has not been discussed in the WG before.
<u></u><u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal">I am curious, is there an emerging use-case
beyond 2.1 and 2.2 quoted below?<u></u><u></u></p>
<p class="MsoNormal">Best,<u></u><u></u></p>
<p class="MsoNormal">Kristina<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> Openid-specs-ab
<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank"><openid-specs-ab-bounces@lists.openid.net></a>
<b>On Behalf Of </b>Vladimir Dzhuvinov via
Openid-specs-ab<br>
<b>Sent:</b> Tuesday, March 29, 2022 8:27 AM<br>
<b>To:</b> <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br>
<b>Cc:</b> Vladimir Dzhuvinov
<a href="mailto:vladimir@connect2id.com" target="_blank"><vladimir@connect2id.com></a><br>
<b>Subject:</b> [Openid-specs-ab] SIOPv2 over NFC?<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p>I wonder if there have been thoughts or considerations of the
NFC protocol for SIOPv2 to interact with RPs?<u></u><u></u></p>
<p>Especially given the adopted use cases 2.1 and 2.2?<u></u><u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<h3 id="gmail-m_-6847854128037062251name-resilience-against-sudden-o"><a href="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" target="_blank">2.1.
</a><a href="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" target="_blank">Resilience against Sudden or
Planned Hosted OP Unavailability</a> <u></u><u></u></h3>
<p id="gmail-m_-6847854128037062251section-2.1-1">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.<u></u><u></u></p>
<h3 id="gmail-m_-6847854128037062251name-authentication-at-the-edge"><a href="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" target="_blank">2.2.
</a><a href="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" target="_blank">Authentication at the Edge</a> <u></u><u></u></h3>
<p class="MsoNormal">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.<u></u><u></u></p>
</blockquote>
<p class="MsoNormal"><u></u> <u></u></p>
<p>~ Vladimir<u></u><u></u></p>
<pre>-- <u></u><u></u></pre>
<pre>Vladimir Dzhuvinov<u></u><u></u></pre>
</div>
</blockquote>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>