[Openid-specs-ab] [Please be careful with the time of the call] SIOP call agenda (2022-Mar-24) - Atlantic call @ 8AM PST/4PM CET

Thu Mar 24 14:17:16 UTC 2022


> Am 24.03.2022 um 14:56 schrieb David Chadwick via Openid-specs-ab <openid-specs-ab at lists.openid.net>:
> 
> On 24/03/2022 13:28, nadalin at prodigy.net <mailto:nadalin at prodigy.net> wrote:
>> Big difference between a browser and a wallet,
> conceptually they are the same. They mediate between the issuer and the RP, and talk directly to the issuer
> 
Well, I think there are important differences. A browser just needs to interpret some HTML code, a wallet manages the user’s keys thus it influences the security of the credential handling. As an issuer and as a verifier I need to know what to expect, otherwise the whole chain from issuer to verifier breaks (for example credentials can be replayed).

In eIDAS2, wallets will be subject to conformity assessment, i.e. not every wallet on earth can be used for use cases under eIDAS 2.
> 
>> its very logical not to mandate, your implementation can mandate but that is your choice not a standards choice. So against this notion.
>>  
>> From: David Chadwick <d.w.chadwick at verifiablecredentials.info> <mailto:d.w.chadwick at verifiablecredentials.info> 
>> Sent: Thursday, March 24, 2022 6:22 AM
>> To: nadalin at prodigy.net <mailto:nadalin at prodigy.net>; 'Artifact Binding/Connect Working Group' <openid-specs-ab at lists.openid.net> <mailto:openid-specs-ab at lists.openid.net>; 'Kristina Yasuda' <Kristina.Yasuda at microsoft.com> <mailto:Kristina.Yasuda at microsoft.com>
>> Subject: Re: [Openid-specs-ab] [Please be careful with the time of the call] SIOP call agenda (2022-Mar-24) - Atlantic call @ 8AM PST/4PM CET
>>  
>> On 24/03/2022 12:44, nadalin at prodigy.net <mailto:nadalin at prodigy.net> wrote:
>> If you mandate this eliminates many use cases, this is a very bad choice to mandate.
>> I dont see why. There is no ability for the RP to chose the browser in standard OIDC, so why should the RP chose the wallet in OIDC4VPs? Its illogical.
>> 
>> The RP chooses the OP in standard OIDC, and chooses the VC Issuers in OIDC4VPs. In other words the RP decides who is the TTP. 
>> 
>> Kind regards
>> 
>> David
>> 
>>  
>> 
>>  
>> From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> <mailto:openid-specs-ab-bounces at lists.openid.net> On Behalf Of David Chadwick via Openid-specs-ab
>> Sent: Thursday, March 24, 2022 5:42 AM
>> To: Kristina Yasuda <Kristina.Yasuda at microsoft.com> <mailto:Kristina.Yasuda at microsoft.com>; Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net> <mailto:openid-specs-ab at lists.openid.net>
>> Cc: David Chadwick <d.w.chadwick at verifiablecredentials.info> <mailto:d.w.chadwick at verifiablecredentials.info>
>> Subject: Re: [Openid-specs-ab] [Please be careful with the time of the call] SIOP call agenda (2022-Mar-24) - Atlantic call @ 8AM PST/4PM CET
>>  
>> On 24/03/2022 09:20, Kristina Yasuda wrote:
>> Hi David,
>> Yes, I will add this to the agenda.
>> However, I will be timeboxing the topic in the interest of making progress on the specifications’ texts – we have a lot of PRs/issues.
>>  
>> I would note that we have already spent a lot of time discussing NASCAR problem last year (see Issue on SIOP Chooser), and I see number of wallets topic is more of a “market force” issue rather technical specification – we cannot control whether an RP supports one or 100 of wallets in a technical specification.
>> Surely we could control this if we mandate only one wallet-independent way of transferring the RP's request (including presentation definition) from the SIOP to the wallet (e.g. using openid:// or something else), which forces the SIOP to ask the user which wallet to use to fulfil the request.  After all, the PD is meant to tell the wallet which VCs are required and the user knows which VCs are in which wallet.
>> 
>> Kind regards
>> 
>> David
>> 
>> Best,
>> Kristina 
>>  
>> From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> <mailto:openid-specs-ab-bounces at lists.openid.net> On Behalf Of David Chadwick via Openid-specs-ab
>> Sent: Thursday, March 24, 2022 10:07 AM
>> To: openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>
>> Cc: David Chadwick <d.w.chadwick at verifiablecredentials.info> <mailto:d.w.chadwick at verifiablecredentials.info>
>> Subject: Re: [Openid-specs-ab] [Please be careful with the time of the call] SIOP call agenda (2022-Mar-24) - Atlantic call @ 8AM PST/4PM CET
>>  
>> Hi Kristina
>>  
>> I wonder if you could add the following topic to the agenda please, since is has been a hot topic on the W3C CCG list this last week:
>>  
>> How to address the NASCAR problem and the centralising effect that RPs might have to try to enforce the user to use a limited number of wallets.
>>  
>> Kind regards
>> 
>> David
>>  
>> On 24/03/2022 01:30, Kristina Yasuda via Openid-specs-ab wrote:
>> <<US moved to the summer time, the call is 4PM CET, 8AM PST, 12AM JST>>
>>  
>> Hi All,
>>  
>> Below is a proposed agenda for the SIOP call.
>>  
>> - IPR reminder/recording
>> - Introductions/re-introductions
>> - Agenda bashing/adoption
>> - Events/External orgs
>> - PRs https://bitbucket.org/openid/connect/pull-requests/ <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fpull-requests%2F&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7Cbc2fe47fd9364955b28b08da0d75afab%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637837097119568421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=xEKQXkNU3GPdWRKUj6kVAZRshfD6hOnygD3YqKX6%2BcA%3D&reserved=0>
>> Discuss - please review (max 15min)
>> PR #138 – oidc4vci: pre-authorized code
>> discuss
>> PR #136 – oidc4vci: clarify holder binding; Issue #1453, #1452
>> Waiting for the examples from Tobias, David C.
>> PR #137 – oidc4vci: mandatory claims
>> Needs more discussion
>> PR #140 – oidc4vci: user consent
>> Discuss, might decline
>> PR #142 oidc4vp: example with anoncreds
>> PR #127 siopv2 – jwk uri
>> - Issues https://bitbucket.org/openid/connect/issues?status=new&status=open&component=SIOP&component=Verifiable%20Presentation&component=Credential%20Issuance <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fissues%3Fstatus%3Dnew%26status%3Dopen%26component%3DSIOP%26component%3DVerifiable%2520Presentation%26component%3DCredential%2520Issuance&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7Cbc2fe47fd9364955b28b08da0d75afab%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637837097119568421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=7bcBQ0iMW%2BDUH0FsdfSBVCsj0pEu%2FH2lnWCviJN9l7U%3D&reserved=0>
>> (Max 15min per issue)
>> #1454: defining a credential type
>> #1461: Supporting HW attestations in the credential request when cryptographic binding is being used
>> Any other issues participants want to discuss
>> - AOB 
>>  
>> 
>> Best,
>> Kristina
>>  
>>  
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
>> https://lists.openid.net/mailman/listinfo/openid-specs-ab <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7Cbc2fe47fd9364955b28b08da0d75afab%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637837097119568421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vKsn93dOEFTlqtqOpMAoQdjK%2BOK7nYGLuVSZ%2BwLWBTU%3D&reserved=0>
>>  
>> 
>>  
>> 
>>  
>> 
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
> https://lists.openid.net/mailman/listinfo/openid-specs-ab <https://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/20220324/23fa25d4/attachment.html>