<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 09/10/2021 20:27, Tom Jones wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAK2Cwb7PtbJ9-XkMxLhUjDcd=No=8C2+-GwtF1_Xs2hsiacemA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">I can understand some parts of that. What I cannot
grok at all is the semantics of a request.</div>
</blockquote>
<p>At the highest semantic level it is Please satisfy the "over 18"
policy, or "apply for a passport policy" etc.<br>
</p>
<p>This semantic policy reference then breaks down into the required
VCs with selective disclosure rules e.g. Please provide (this list
of attributes from this type of VC from this Issuer/Trust
Federation) and/or (this list of attributes from this type of VC
from this Issuer/Trust Federation) and/or [ad infinitum]</p>
<blockquote type="cite"
cite="mid:CAK2Cwb7PtbJ9-XkMxLhUjDcd=No=8C2+-GwtF1_Xs2hsiacemA@mail.gmail.com">
<div dir="ltr"> Let's consider the DHS S&T request for
providing proof-of-ability-to-work. Each country/region has its
own set of documents that do that. </div>
</blockquote>
<p>The DHS S&T has to set its policy for providing proof of
ability to work. It decides which countries and regions it trusts,
and which documents it wants from each of them. This policy can be
described mathematically in DNF or CNF.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAK2Cwb7PtbJ9-XkMxLhUjDcd=No=8C2+-GwtF1_Xs2hsiacemA@mail.gmail.com">
<div dir="ltr">Some leak information by their very existence. I
guess the user could be asked to disambiguate a request</div>
</blockquote>
<p>Yes. The wallet will evaluate the policy and select all the VCs
that contribute to matching the policy. Then the user will be
asked which of the possible alternatives to choose.</p>
<p>In the case of multiple wallets that each provide a subset of the
policy, the user will have to switch between apps and submit
multiple subsets from each one. This is obviously a real pain for
the user, but until there is a universal wallet that all issuers
are happy with and trust, I don't see an alternative.<br>
</p>
<blockquote type="cite"
cite="mid:CAK2Cwb7PtbJ9-XkMxLhUjDcd=No=8C2+-GwtF1_Xs2hsiacemA@mail.gmail.com">
<div dir="ltr"> - in that case the consent request would have more
than one choice for the user to select from? </div>
</blockquote>
<p>Yes correct. Just like when you go to the supermarket, you can
choose between Visa, Amex and Mastercard to pay.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAK2Cwb7PtbJ9-XkMxLhUjDcd=No=8C2+-GwtF1_Xs2hsiacemA@mail.gmail.com">
<div dir="ltr">Or better i guess the chooser could list the
choices with one pre-selected? (I think I am beginning to see a
hazy path thru the minefield.)
<div><br>
</div>
<div>Is any work in progress to create a semantic for cred
types?</div>
</div>
</blockquote>
<p>The type field is currently the unambiguous semantic for the VC.
All VCs of the same type will have the same URI value. The
@context mapping turns this into a user friendly string such as
"degree certificate", "driving license" etc.</p>
<p>Kind regards</p>
<p>David<br>
</p>
<blockquote type="cite"
cite="mid:CAK2Cwb7PtbJ9-XkMxLhUjDcd=No=8C2+-GwtF1_Xs2hsiacemA@mail.gmail.com">
<div dir="ltr">
<div>
<div><br clear="all">
<div>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap">Be the change you want to see in the world </span>..tom</div>
</div>
</div>
</div>
<br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, Oct 9, 2021 at 12:09
PM David Chadwick <<a
href="mailto:d.w.chadwick@verifiablecredentials.info"
moz-do-not-send="true">d.w.chadwick@verifiablecredentials.info</a>>
wrote:<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>
<div>On 09/10/2021 17:33, Tom Jones wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">I understood and agreed with that up to the
part about Chooser selecting multiple wallets.
<div><br>
</div>
<div>Here is what I cannot get my head around. When the
client makes a request (JAR, whatever) that involves
creds in different wallets. How or who decides the
split - or does every wallet get the entire request?
But even then, where/how does the response (the ID
token) get created. Sending separate ID tokens does
not seem like a useful solution to me. Altho perhaps a
collection of ID tokens might work if they all went in
one packet.</div>
</div>
</blockquote>
<p>This is still active research and a work in progress. My
current mental model is that wallets will register with
the SIOP chooser, registering the VCs that they can
provide, and SIOP will pass the request on to those that
can fulfil part of the policy, or will reject the request
if it knows the policy cannot be 100% fulfilled by its
registered wallets. The OIDC protocol already supports
sets of VPs, so if each wallet returns a VP, the SIOP can
merge these into an OIDC response. Policy communication
will be via reference to the semantic policy, so that each
wallet can retrieve the policy in the syntax they support.</p>
<p>Kind regards</p>
<p>David<br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div><br clear="all">
<div>
<div dir="ltr">
<div dir="ltr">
<div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap">Be the change you want to see in the world </span>..tom</div>
</div>
</div>
</div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, Oct 9, 2021 at
3:05 AM David Chadwick <<a
href="mailto:d.w.chadwick@verifiablecredentials.info"
target="_blank" moz-do-not-send="true">d.w.chadwick@verifiablecredentials.info</a>>
wrote:<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>
<div><br>
</div>
<div>On 08/10/2021 21:44, Tom Jones wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">As Mike has noted earlier, the
wallet you describe needs to be the only wallet
that the user has on their device. Very few of
us believe that is possible, unless some
gigantic social media company takes control. </div>
</blockquote>
<p>It is possible that Apple and Google wallets will
eventually become the only wallets that people
have on their smartphones. It is likely, with mDL
and their existing credit card support, that this
will leap frog them into pole position. OTOH it is
also possible that federations will specify the
wallets, policies and VCs that they will accept
within their federation.<br>
</p>
<p>Until we have global dominance, it likely that
users will hold many different wallets as you say.
The SIOP (chooser) component will need to pass the
policy onto the different wallets for them to
satisfy components of this. Having the same
semantic policy encoded in different syntaxes will
enable different proprietary wallets to interwork
with the SIOP chooser.</p>
<p>Kind regards</p>
<p>David<br>
</p>
<blockquote type="cite">
<div dir="ltr">The sorts of wallets that are
contemplated today cannot hope to handle
arbitrary credentials of the sorts that users
will need in their day-to-day life. My own
university tells me which wallet I can use to
hold my VC diploma. My state tells me which
wallets are trusted to hold my mDL.
<div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap">
</span></div>
<div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap"> </span>..tom<br>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Oct 8,
2021 at 12:07 PM David Chadwick via
Openid-specs-ab <<a
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank" moz-do-not-send="true">openid-specs-ab@lists.openid.net</a>>
wrote:<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>
<div>I would like to discuss the layering of
OIDC with VCs, so that the application
layer would simply pass a policy reference
to the SIOP wallet and the wallet would
respond with a (set of) VP(s), using the
OIDC protocol. Then the management layer
on top of this could define whatever
policies it wanted to for requesting
combinations of VCs, with or without
selective disclosure, so that different
federations with their own wallets can
implement their own policies suitable for
their requirements.<br>
<br>
This will decouple OIDC from presentation
exchange (which in my opinion is too
complex for the majority of use cases).</div>
<div><br>
</div>
<div>Comments?</div>
<div>Kind regards</div>
<div>David</div>
<div><br>
</div>
<div><br>
</div>
<div>On 08/10/2021 19:36, Mike Jones via
Openid-specs-ab wrote:<br>
</div>
<blockquote type="cite">
<div>
<p class="MsoNormal">I took the action
item to bring people’s concerns about
the paucity of relevant IIW sessions
to Phil Windley’s attention. Both he
and Heidi essentially responded that
“It’s open space – make what you want
to have happen happen.” Which is
fair.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">They suggested that
we use the IIW wiki pages <a
href="https://iiw.idcommons.net/IIW_33_Proposed_Topics"
target="_blank"
moz-do-not-send="true">
https://iiw.idcommons.net/IIW_33_Proposed_Topics</a>
and <a
href="https://iiw.idcommons.net/IIW_33_Time_Zone_Session_Planning"
target="_blank"
moz-do-not-send="true">
https://iiw.idcommons.net/IIW_33_Time_Zone_Session_Planning</a>
to coordinate and schedule clusters of
sessions that we want to see. They
were supportive of people trying to
organize in advance to get the most
out of IIW.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">
-- Mike</p>
<p class="MsoNormal"> </p>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank" moz-do-not-send="true">Openid-specs-ab@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank" moz-do-not-send="true">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<p><br>
</p>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a
href="mailto:Openid-specs-ab@lists.openid.net"
target="_blank" moz-do-not-send="true">Openid-specs-ab@lists.openid.net</a><br>
<a
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote>
</div>
</blockquote>
<p><br>
</p>
</div>
</blockquote>
</div>
</blockquote>
<p><br>
</p>
</div>
</blockquote>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>