Privacy considerations missing in OAuth profile

[Nat Sakimura]

While we do have one in OIDC profile, we do not have a privacy considerations section in OAuth 2.0 profile.

In today (May 2) call, SNI and domain sniffing with TLS 1.2 came up so I thought it might worth considering such.

[Tom Clancy]

Changed to BLOCKER to filter for v1.05/Implementer’s draft.

[Tom Clancy]

Final: OpenID Connect Core 1.0 incorporating errata set 2

OpenID Core Section 17. Privacy Considerations

17.1. Personally Identifiable Information. (require specific purpose for UserInfo access, typically registered with redirect_uris, as well as minimization at client)

17.2. Data Access Monitoring (allow users to view UserInfo access logs)

17.3. Correlation (consider pairwise pseudonymous identifier/PPID for sub)

17.4. Offline Access (use of prompt and valid consent)

iGov OIDC Profile Section 5. Privacy Considerations:

Data minimization is an essential concept in trust frameworks and federations exchanging user identity information for government applications. The design of this specification takes into consideration mechanisms to protect the user's government identity information and activity from unintentional exposure.¶

Pairwise anonymous identifiers MUST be supported by the OpenID Providers for frameworks where subjects should not be traceable across clients by their subject ID. This prevents a situation where a user may inadvertently be assigned a universal government identifier.

Request claims MUST be supported by the OpenID Providers to ensure that only the data the client explicitly requests is provided in the UserInfo response. This prevents situations where a client may only require a partial set of claims, but receives (and is therefore exposed to) a full set of claims. For example, if a client only needs a single government document type and number, the OpenID Provider MUST NOT send the client the full document information, possibly from multiple documents.

Despite the mechanisms enforced by this specification, the operational circumstances of a federation may allow these controls to be relaxed. For example, if a framework always requires clients to request a national ID number, then the pairwise anonymous identifer requirement may be relaxed. In cases where all clients are entitled to all government document claims associated to a subject at an OpenID Provider, the claims request requirement may be relaxed.

The reasons for relaxing the controls that support data minimalization are outside the scope of this specification.

Question: Are there downstream iGov OAuth 2.0 profiles that include privacy considerations?

[Kelley Burgin]

Look at RFC6973 https://datatracker.ietf.org/doc/html/rfc6973

[Tom Clancy]

RFC 6973 “Considerations” are addressed with normative language in the main profile, leaving no privacy considerations for a separate section; recommend resolving this issue pending identification of privacy “considerations”