[Openid-specs-ab] (Draft Proposal) OpenID Connect Ephemeral Identifier Subject Type (re: Issue #1096)

Nat Sakimura nat at nat.consulting
Mon Nov 9 07:32:03 UTC 2020


Dear AB/C WG members:

Below is a draft proposal for OpenID Connect Ephemeral Identifier Subject
Type.
It has been discussed as issue #1096.

I still think that incorporating it in the Core is better as that will
inform the readers of the fact, but if it needs to be a new document, then
this could be used as the basis for adoption in the WG and subsequently
going to WG last call immediately.

Best,

Nat Sakimura

OpenID Connect Ephemeral Identifier Subject TypeAbstract

This document defines a new subject type to signal a client that the
subject identifier changes whenever a new authentication request is made.
*1. Introduction*

OpenID Connect Core 1.0 defines in clause 8 two subject identifier types.
Both of them are durable. However, there are cases where the use of an
ephemeral identifier is desirable, such as only over-age or not is needed
by the client. It is sometimes referred to as anonymous attribute-based
authentication or unlinkable attribute-based authentication. While it was
always in the use-case of OpenID Connect, the subject identifier type for
it was never defined. This document defines it.
1.1. Requirements Notation and Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in *RFC 2119*
<https://openid.net/specs/openid-connect-core-1_0.html#RFC2119> [RFC2119].
*2. Normative references*

[OIDC] OpenID Connect Core 1.0
*3. Terms and definitions*

This document uses terms defined in [OIDC].
*4. Symbols and abbreviations*

OIDC OpenID Connect
*5. Subject Identifier Types*

Subject identifier types are defined in clause 8 of [OIDC]. This document
defines a new additional subject identifier type.

*ephemeral*

This indicates that a different sub value will be returned to each
authentication request by a Client, so as not to enable Clients to
correlate the End-User's visits to it.


*6. Security considerations*

When an ephemeral identifier is created, it is often a case that a
pseudo-random value is used. Depending on the function used, a duplicate
value could result. This should be avoided by using a cryptographically
random function. Use of date bound value may reduce the chance of
duplication.
*7. Privacy considerations*

While the sub value provided in compliance with this document may protect
the End User from correlation, it should be noted that other correlation
methods are possible. For example, the client may collect IP Address,
Browser cookie, Browser font-lists, etc. Such values combined collectively
know as device-fingerprint may be sufficient to identify the End-user. OP
should let the user know the fact.
*8. Acknowledgement**8.1 Author(s)*

Nat Sakimura, NAT Consulting LLC
*8.2 Contributors*

TBD


-- 
Nat Sakimura
NAT.Consulting LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20201109/c0f46417/attachment.html>


More information about the Openid-specs-ab mailing list