<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I think there are two levels to introduce NFC:<div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">thoughts?</div><div class=""><br class=""></div><div class="">best regards,</div><div class="">Torsten. </div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">Am 30.03.2022 um 22:45 schrieb Giuseppe De Marco via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a>>:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi Vladimir,<br class="">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 class=""><br class="">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 class=""><br class="">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 class=""><br class="">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 class=""><br class="">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 class=""><br class="">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 class=""><br class="">best</div><br class=""><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" class="">openid-specs-ab@lists.openid.net</a>> ha scritto:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><p class="">Hi Kristina,</p><p class="">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 class="">
</p><p class="">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 class="">
</p><p class="">Vladimir<br class="">
</p>
<pre cols="72" class="">Vladimir Dzhuvinov</pre>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">On 29/03/2022 20:32, Kristina Yasuda
wrote:<br class="">
</div>
<blockquote type="cite" class="">
<div class=""><p class="MsoNormal">Hi Vladimir,<u class=""></u><u class=""></u></p><p class="MsoNormal">Thank you for the question! SIOPv2 over NFC
has not been discussed in the WG before.
<u class=""></u><u class=""></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 class=""></u><u class=""></u></p><p class="MsoNormal">I am curious, is there an emerging use-case
beyond 2.1 and 2.2 quoted below?<u class=""></u><u class=""></u></p><p class="MsoNormal">Best,<u class=""></u><u class=""></u></p><p class="MsoNormal">Kristina<u class=""></u><u class=""></u></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p>
<div class="">
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in" class=""><p class="MsoNormal"><b class="">From:</b> Openid-specs-ab
<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank" class=""><openid-specs-ab-bounces@lists.openid.net></a>
<b class="">On Behalf Of </b>Vladimir Dzhuvinov via
Openid-specs-ab<br class="">
<b class="">Sent:</b> Tuesday, March 29, 2022 8:27 AM<br class="">
<b class="">To:</b> <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank" class="">openid-specs-ab@lists.openid.net</a><br class="">
<b class="">Cc:</b> Vladimir Dzhuvinov
<a href="mailto:vladimir@connect2id.com" target="_blank" class=""><vladimir@connect2id.com></a><br class="">
<b class="">Subject:</b> [Openid-specs-ab] SIOPv2 over NFC?<u class=""></u><u class=""></u></p>
</div>
</div><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="">I wonder if there have been thoughts or considerations of the
NFC protocol for SIOPv2 to interact with RPs?<u class=""></u><u class=""></u></p><p class="">Especially given the adopted use cases 2.1 and 2.2?<u class=""></u><u class=""></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt" class="">
<h3 id="gmail-m_-6847854128037062251name-resilience-against-sudden-o" class=""><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" class="">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" class="">Resilience against Sudden or
Planned Hosted OP Unavailability</a> <u class=""></u><u class=""></u></h3><p id="gmail-m_-6847854128037062251section-2.1-1" class="">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 class=""></u><u class=""></u></p>
<h3 id="gmail-m_-6847854128037062251name-authentication-at-the-edge" class=""><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" class="">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" class="">Authentication at the Edge</a> <u class=""></u><u class=""></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 class=""></u><u class=""></u></p>
</blockquote><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="">~ Vladimir<u class=""></u><u class=""></u></p>
<pre class="">-- <u class=""></u><u class=""></u></pre>
<pre class="">Vladimir Dzhuvinov<u class=""></u><u class=""></u></pre>
</div>
</blockquote>
</div>
_______________________________________________<br class="">
Openid-specs-ab mailing list<br class="">
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank" class="">Openid-specs-ab@lists.openid.net</a><br class="">
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank" class="">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br class="">
</blockquote></div>
_______________________________________________<br class="">Openid-specs-ab mailing list<br class=""><a href="mailto:Openid-specs-ab@lists.openid.net" class="">Openid-specs-ab@lists.openid.net</a><br class="">https://lists.openid.net/mailman/listinfo/openid-specs-ab<br class=""></div></blockquote></div><br class=""></div></body></html>