[Openid-specs-ab] IIW Session Planning

[Tom Jones]

I take the view that we create the chooser w/o any new browser support and
then work with one of the vendors to create a proposal for changing the
browser to make it work that way.  It is much easier to make a case if we
know exactly what it is that we want. I suspect it will be some combo of
the p/w manager and the protocol picker.

I am not at all certain that anyone really understands what a useful
semantic will be. After all, we have had this capability for over 20 years
in xml and never make it truly useful.


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


On Sat, Oct 9, 2021 at 7:50 PM David Waite <david at alkaline-solutions.com>
wrote:

> 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 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
>>>
>>
>> _______________________________________________
> 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/f974220a/attachment.html>