Context for credentials and other permissions

[npdoty]

Session description

In presenting government-issued credentials or making other significant permission decisions, users need more information about how their data will be used. This session will discuss potential changes to the Web platform to give additional info on how and why a permission will be used. Everyone welcome, especially people working on credentials, permissions and privacy on the Web.

We have long struggled with how the Web platform can design permissions requests so that users can make informed decisions about granting access. Today, users rarely have the information that they need to understand how a granted permission will be used or what will happen with their data, and they often either ignore a flood of requests or shrug and grant them to get them to go away. This is not only bad for user privacy but also for site developers who want to use these capabilities. Good practices exist but aren’t often encouraged or enabled by the design of the Web platform. Permissions requests that go across devices or between apps (like to a wallet) add further challenges.

In this session, we will consider a few of the options – enums, purpose strings, well-known files, surrounding Web context. What would be needed to add trustworthy, explainable contextual information to a permission request using these or other methods? The example of asking for information from a government-issued credential will be a key case study, but we can also consider how other APIs could take advantage of additional context.

Session goal

Describing promising methods to provide context for permission requests and identifying volunteers who want to explore them, for future incubation and experimentation, in credentials and other APIs.

Additional session chairs (Optional)

No response

Who can attend

Anyone may attend (Default)

IRC channel (Optional)

permissions-context

Other sessions where we should avoid scheduling conflicts (Optional)

64, #18, #10, #8

Instructions for meeting planners (Optional)

No response

Agenda for the meeting.

No response

Links to calendar

• 2024-09-25, 13:15 - 14:15

[tpac-breakout-bot]

Thank you for proposing a session!

You may update the session description as needed and at any time before the meeting, but please keep in mind that tooling relies on issue formatting: follow the instructions and leave all headings and other formatting intact in particular. Bots and W3C meeting organizers may also update the description, to fix formatting issues or add links and other relevant information. Please do not revert these changes. Feel free to use comments to raise questions.

Do not expect formal approval; W3C meeting organizers endeavor to schedule all proposed sessions that are in scope for a breakout. Actual scheduling should take place shortly before the meeting.

[npdoty]

(Thanks Pete, Don, Jeffrey, Tim, maybe some others for feedback)

[npdoty]

It's possible that #64 in particular is a very similar topic, so we may want to merge these sessions, or otherwise identify which permissions (and identity) sessions would work best separate or combined. /cc @alexandrareimers

[mikewest]

@ianbjacobs: I agree with @npdoty that this and #64 should likely be combined, as we're otherwise splitting the potential audience across two sessions. I'd vaguely prefer we consolidate into the earlier slot, but I don't have a strong opinion about which we choose (there are other meetings I personally would like to attend in both!). :)

[ianbjacobs]

@alexandrareimers and @npdoty, thanks for working together on this. I'm happy to combine them. I propose that @npdoty suggest changes to #64's description. And we need to pick a time slot: either 11:15 or 13:15.

I can make the changes once there's agreement. Thanks!

[npdoty]

+1 for the earlier time slot. I'll work with @alexandrareimers on any changes to #64 description.

[ianbjacobs]

Ok, I'll close this session. Your updates to #64 will automatically propagate to the meeting pages and calendar. Thanks!