[Openid-specs-ab] IIW Session Planning

[David Waite]

The pr proposal i made would be that there can be openid metadata defining capabilities, such as presenting smart health cards or mdl, supporting different DID schemes, etc.

A wallet would choose which ones it supports. Some issuers, like self-issued/v2, are self certifying while others may be under a more controlled process. Self-issued/v2 isn’t great for more complex queries like presentation exchange, since you are now asking for capabilities that weren’t required/specified in the base metadata. 

You say your app supports operation as a particular issuer by catching the authorization_endpoint.

This still leaves the possibility that the underlying platform or browser won’t present a multiple choice option to the user (which we still need to work toward fixing imho) but makes it far more likely that the request will go to some piece of software designed to handle that type of request or that vertical. 

Sent from my iPhone

> On Oct 9, 2021, at 10:34 AM, Tom Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net> 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.
> 
> 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 list
>>>>> Openid-specs-ab at lists.openid.net
>>>>> http://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
>> 
> _______________________________________________
> 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/9d166022/attachment.html>