[Openid-specs-ab] IIW Session Planning

[Tom Jones]

I understood and agreed with that up to the part about Chooser
selecting multiple wallets.

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.

Be the change you want to see in the world ..tom


On Sat, Oct 9, 2021 at 3:05 AM David Chadwick <
d.w.chadwick at verifiablecredentials.info> wrote:

>
> On 08/10/2021 21:44, Tom Jones wrote:
>
> 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.
>
> 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.
>
> 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.
>
> Kind regards
>
> David
>
> 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.
> ..tom
>
>
> On Fri, Oct 8, 2021 at 12:07 PM David Chadwick via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
>> 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.
>>
>> This will decouple OIDC from presentation exchange (which in my opinion
>> is too complex for the majority of use cases).
>>
>> Comments?
>> Kind regards
>> David
>>
>>
>> On 08/10/2021 19:36, Mike Jones via Openid-specs-ab wrote:
>>
>> 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.
>>
>>
>>
>> They suggested that we use the IIW wiki pages
>> https://iiw.idcommons.net/IIW_33_Proposed_Topics and
>> https://iiw.idcommons.net/IIW_33_Time_Zone_Session_Planning 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.
>>
>>
>>
>>                                                        -- Mike
>>
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://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/20211009/319e3eec/attachment.html>