[Openid-specs-ab] IIW Session Planning

[Tom Jones]

I can understand some parts of that.  What I cannot grok at all is the
semantics of a request. 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. Some leak information by their very existence. I guess the
user could be asked to disambiguate a request - in that case the consent
request would have more than one choice for the user to select from? 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.)

Is any work in progress to create a semantic for cred types?

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


On Sat, Oct 9, 2021 at 12:09 PM David Chadwick <
d.w.chadwick at verifiablecredentials.info> wrote:

> On 09/10/2021 17:33, Tom Jones wrote:
>
> 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.
>
> 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.
>
> Kind regards
>
> David
>
>
> 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/7cc556d4/attachment.html>