LINKSPREED

LINKSPREED Is Building Granular Consent for UIID: Users Decide What Apps Can Access and for How Long

LINKSPREED is developing a new consent system for the OAuth2 flow of UIID. Users approve each permission individually, set how long access lasts, and are asked for more only when needed.

LINKSPREED uiidconsentprivacy

A first version of selective permissions, time-limited access and step-up authorization is planned for UIID v2.14

LINKSPREED is developing a new consent system for the OAuth2 flow of UIID, its privacy-first identity layer. The first version is planned for UIID v2.14. Users will be able to approve each permission an app requests individually, decide how long the access lasts, and be asked for additional permissions later only when an app actually needs them.

About UIID: identity that stays with the person

UIID is LINKSPREED’s identity layer, built around the idea that a digital identity should belong to the person using it, not to the platform they log in to. It is built on a few core building blocks:

  • Device-bound authentication. Access is tied to the user’s own device instead of a password that can be stolen, reused or guessed.
  • Passkeys. UIID supports passkeys, so people can sign in with the biometrics or screen lock they already use on their device.
  • Aliases. Users can present themselves to different apps and services with different aliases instead of one identity that can be tracked everywhere.
  • Badges. Users can show verified attributes without handing over more personal data than necessary.

Apps and services can connect to UIID through OAuth2. This is the same family of standards that many developers already know from “Sign in with …” buttons. The new consent system builds directly on this flow, so developers do not have to learn a new technology.

In most authorization flows today, an app asks for several permissions at once. A typical request might include profile data, an email address and the right to create aliases. The user sees one screen with one decision: accept everything or leave.

This causes three problems:

  • Users give away more than needed. Even if an app only needs a name, the user has to agree to every permission on the list.
  • Access lasts longer than the task. A one-time action, such as confirming an identity or creating a single alias, often leaves the app with long-lasting access.
  • Apps ask for everything upfront. Developers tend to request every permission they might ever need, because asking again later is awkward.

For a platform whose purpose is to give people control over their identity, this is not good enough. That is why LINKSPREED is working on a more granular approach.

Hero Image

What is planned for the first version

On the approval page, users will see a checkbox for each permission the app requests. A user can accept some permissions and decline others. For example, someone can share their profile with an app and still decide that the app may not create aliases on their behalf.

Required scopes set by the app

Not every permission is optional. Some apps cannot work without certain data. For this, an app can use a new URL parameter called required_scopes to mark which permissions are mandatory. In the approval screen, these permissions appear locked and stay switched on. All other permissions remain a free choice for the user.

This keeps things honest for both sides. Users can see exactly what an app truly needs and what it only wants to have. Developers can state clearly what is essential for their app to work.

Choose how long access lasts

Users will also decide how long an app may keep its access:

  • Permanent. The access stays in place until it is changed or removed.
  • Single Execution / Temporary. The access token expires after 15 minutes (900 seconds).

The temporary option is made for one-time actions. If an app only needs to do one thing, it does not need to keep access afterwards. If a token with a short lifetime is ever leaked, the damage is limited because it expires quickly.

Asking for missing permissions later (step-up authorization)

Sometimes an app wants to do something the user declined earlier. With the new system, the API will not silently fail or quietly allow the action. It responds with an HTTP 403 Forbidden status and includes a ready-made authorization_url in the JSON response.

The app only has to send the user to this link. The user is then asked for the one missing permission, not for everything again. This is often called incremental authorization or step-up authorization.

An example flow:

  1. A user connects an app to UIID. They share their profile but decline the permission to create aliases.
  2. Later, the user starts an action in the app that needs a new alias.
  3. The app sends the request to the UIID API. The API replies with 403 Forbidden and an authorization_url.
  4. The app sends the user to that link. The user sees only the single missing permission and can approve or decline it.
  5. If the user approves, the app can continue. If the user declines, nothing changes and the user stays in control.

This way, permissions grow with the actual need, and the request always happens at a moment when the user understands why it is being asked.

Compatible with existing apps

LINKSPREED has designed the feature so that existing integrations do not break. If an app does not use required_scopes, the flow works the way it does today. Developers can adopt the new options step by step, when it suits them.

Why this matters

For users

  • More control. People decide which data they share and for how long.
  • Clearer choices. Locked and optional permissions are visible and easy to tell apart.
  • Fewer surprises. Extra permissions are only requested when they are needed.

For privacy and compliance

  • Data minimization. Apps only receive what the user approves. This supports the data minimization principle of the GDPR.
  • Lower risk. Short-lived tokens reduce the impact of leaked credentials.

For developers

  • A clear standard pattern. The 403 response with a ready-made authorization_url gives apps a simple, predictable way to ask for additional permissions.
  • No forced migration. Existing integrations continue to work unchanged.
  • Less unnecessary data. Apps that request fewer permissions upfront may build more trust with their users.

Hero Image

Software is increasingly acting on behalf of people, including automated tools and AI agents. When something acts for a user, the question is not only who the user is, but also what exactly it is allowed to do and for how long. Selective permissions, short-lived access and step-up authorization are the building blocks for answering that question. LINKSPREED sees this consent system as an important foundation for UIID’s further development as an identity layer.

Availability

The consent system is in development. A first version is planned for UIID v2.14. Scope and details may change before release. LINKSPREED will share further updates as the release gets closer.

About UIID

UIID is LINKSPREED’s privacy-first identity layer. It is built around device-bound authentication, aliases, badges and passkeys, and it aims to give people control over how they appear and what they share online. Learn more at https://uiid.me.

About LINKSPREED

LINKSPREED builds privacy-focused identity and social technology, including UIID.

← All articles