Subject: [Id-event] Comments on draft-ietf-secevent-subject-identifiers

From: Denis <[email-masked]>
Date: Mon, 15 Mar 2021 11:15:09 +0100

Hello Annabelle and Marius,

I am a participant to the GNAP WG. Since the 
draft-ietf-secevent-subject-identifiersis mentioned in the 
draft-ietf-gnap-core-protocol, I took a look at it.

Last week, I sent to both of you two emails and since I got no response 
(your anti-spam software might be too effective), I have subscribed to 
the SECEVENT mailing list,
to make sure that this email will reach you.

I have two sets of comments.
*
Firstly, about the title and the abstract
*
The definition of Subject Identifier in the draft-07 (section 3) is :

    A Subject Identifier is a JSON [RFC7159] object whose contents may
    be used to identify a subject */within some context/**.*

However, page 2 of the draft-07 states:

       As described in Section 1.2 of SET [RFC8417], subjects */related
    to/**
    **/  security events/* may take a variety of forms, including but not
       limited to a JWT [RFC7519] principal, an IP address, a URL, etc.

RFC 8417 (Security Event Token (SET)) states in its abstract:

        Abstract

        This specification defines the /Security Event Token (SET) data///
    /   structure/.  A SET describes statements of fact from the perspective
        of an issuer about a subject.  These statements of fact represent an
        event that occurred directly to or about a security subject, for
        example, a statement about the issuance or revocation of a token on
        behalf of a subject.  This specification is intended to enable
        representing security- and identity-related events.  A SET is a JSON
        Web Token (JWT), which can be optionally signed and/or encrypted.
        SETs can be distributed via protocols such as HTTP.

There is a need to be able to use subject identifiers that will /not 
necessarily be used in a Security Event Token (SET) data structure./

These Subject Identifiers might still be used in a Security Event Token 
(SET) data structure, /but not necessarily/.

The current title of the draft is: "Subject Identifiers for Security 
Event Tokens" .

More appropriate titles would be:

    Subject Identifiers for Security Event Tokens /and other purposes/

or simply

    Subject Identifiers

The first sentence from the abstract should slightly be reworded or 
could even be removed. Currently, it is:

    Security events communicated within Security Event Tokens may
    support a variety of identifiers to identify the subject and/or
    other principals related to the event.

*Then after, about the content of the draft*

**In the GNAP WG, it is envisioned to request some /_types_ /of subject 
identifiers to be placed into an access token, then to place some 
subjects identifiers
(with their values) into an access token and for a RS (Resources Server) 
to compare these subjects identifiers (with their values) against 
validation rules
originating from RO (Resource Owner) acting as an ADF (Access Decision 
Function) which also use the same subjects identifiers (with their values).

In order to address privacy concerns, it is desirable to make a 
difference between:

    (1) a globally unique identifier (e.g. an email address, a social
    security number or a DID (Decentralized Identifier), gu_id
    (2) an identifier locally unique to that AS for all the RSs, as_id
    (3) an identifier unique for every AS - RS pair, or rs_id
    (4) a temporary identifier for a single session (i.e. a large random
    identifier), session_id

More info is available in the slides 9 to 12 presented at the last IETF 
110 GNAP WG virtual meeting. These slides are available at:
https://datatracker.ietf.org/meeting/110/materials/slides-110-gnap-gnap-model-and-trust-relationships-00 
<https://datatracker.ietf.org/meeting/110/materials/slides-110-gnap-gnap-model-and-trust-relationships-00>

For example, for a globally unique identifier:

"sub_id": {
"subject_type": "gu_id"
"gu_id": " email",
"email: "[email-masked]" <mailto:[email-masked]>,
}

or

"sub_id": {
"subject_type": "gu_id"
"gu_id": "ssn ",
"cn": 250
"ssn ": "170065550100",
}

or

"sub_id": {
"format": "gu_id",
"gu_id": " did",
"did: "did:/DID:Method:DID Method Specific String/",
}

For example, for an identifier locally unique to that AS for all the RSs

"sub_id": {
"format": "as_id"
"iss": "http://issuer.example.com/" <http://issuer.example.com/>,
"id": "john_hughes.com",
}

For example, foran identifier unique for one AS - RS pair

"sub_id": {
"format": "rs_id",
"iss": "http://issuer.example.com/" <http://issuer.example.com/>,
"rs": "_http://server.com/_"
"id": "1452345734788822",
}

For example, fora temporary identifier valid for a single session

"sub_id": {
"format": "session_id"
"iss": "http://issuer.example.com/" <http://issuer.example.com/>
"session_id": "A57B893E17F6471D",
}

When supporting RBAC (Role Based Access Control), it would be nice to 
define a "sub_id" able to support roles.

For example, foran identifier supporting a role:

"sub_id": {
"format": "as_role",
"iss": "http://issuer.example.com/" <http://issuer.example.com/>,
"role": "science/teacher",
}

or

"sub_id": {
"format": "as_role",
"iss": "http://issuer.example.com/" <http://issuer.example.com/>,
"role": "auditor",
}

When supporting ABAC (Attribute Bases Access Control), it would be nice 
to define a "sub_id" able to support group memberships.
For example, foran identifier supporting a group membership:

"sub_id": {
"subject_type": "as_grp",
"iss": "http://issuer.example.com/" <http://issuer.example.com/>,
"grp": "university/science/teacher",
}

Denis

---

From: Justin Richer <[email-masked]>
Date: Wed, 17 Mar 2021 08:55:53 -0400

I just want to clarify one specific point from Denis’s message:

> In the GNAP WG, it is envisioned to request some types of subject identifiers to be placed into an access token, then to place some subjects identifiers 
> (with their values) into an access token and for a RS (Resources Server) to compare these subjects identifiers (with their values) against validation rules 
> originating from RO (Resource Owner) acting as an ADF (Access Decision Function) which also use the same subjects identifiers (with their values).
> 

This is not accurate. In GNAP, there is functionality to request some types of subject identifiers for the purpose of communicating them directly to the client instance. GNAP does not prescribe a token format, and does not specify any method of putting subject identifiers into an access token, nor of communicating subject identifiers to the RS for comparison or validation. 

 — Justin

> On Mar 15, 2021, at 6:15 AM, Denis <[email-masked]> wrote:
> 
> I am a participant to the GNAP WG. Since the draft-ietf-secevent-subject-identifiers is mentioned in the draft-ietf-gnap-core-protocol, I took a look at it. 
> 
> Last week, I sent to both of you two emails and since I got no response (your anti-spam software might be too effective), I have subscribed to the SECEVENT mailing list, 
> A Subject Identifier is a JSON [RFC7159] object whose contents may be used to identify a subject within some context.  
>   As described in Section 1.2 of SET [RFC8417], subjects related to
>   security events may take a variety of forms, including but not
>    This specification defines the Security Event Token (SET) data
>    structure.  A SET describes statements of fact from the perspective
> There is a need to be able to use subject identifiers that will not necessarily be used in a Security Event Token (SET) data structure.
> 
> 
> These Subject Identifiers might still be used in a Security Event Token (SET) data structure, but not necessarily.
> 
> The current title of the draft is: "Subject Identifiers for Security Event Tokens" .
> Subject Identifiers for Security Event Tokens and other purposes
> or simply
> 
> 
> Subject Identifiers
> The first sentence from the abstract should slightly be reworded or could even be removed. Currently, it is:
> 
> 
> Security events communicated within Security Event Tokens may support a variety of identifiers to identify the subject and/or other principals related to the event. 
> Then after, about the content of the draft
> 
> 
> In the GNAP WG, it is envisioned to request some types of subject identifiers to be placed into an access token, then to place some subjects identifiers 
> (with their values) into an access token and for a RS (Resources Server) to compare these subjects identifiers (with their values) against validation rules 
> originating from RO (Resource Owner) acting as an ADF (Access Decision Function) which also use the same subjects identifiers (with their values).
> 
> In order to address privacy concerns, it is desirable to make a difference between:
> (1) a globally unique identifier (e.g. an email address, a social security number or a DID (Decentralized Identifier), gu_id
> (4) a temporary identifier for a single session (i.e. a large random identifier), session_id
> 
> More info is available in the slides 9 to 12 presented at the last IETF 110 GNAP WG virtual meeting. These slides are available at:
> https://datatracker.ietf.org/meeting/110/materials/slides-110-gnap-gnap-model-and-trust-relationships-00 <https://datatracker.ietf.org/meeting/110/materials/slides-110-gnap-gnap-model-and-trust-relationships-00>
> 
>        "did: "did:DID:Method:DID Method Specific String",
>      }
> 
> For example, for an identifier unique for one AS - RS pair
> 
> "sub_id": {
>      "format": "rs_id",
>      "rs": "http://server.com/ <http://server.com/>"
> For example, for a temporary identifier valid for a single session
> 
> "sub_id": {
>        "format": "session_id"
> When supporting RBAC (Role Based Access Control), it would be nice to define a "sub_id" able to support roles.
> 
> 
> For example, for an identifier supporting a role:
> 
> "sub_id": {
>      "format": "as_role",
> When supporting ABAC (Attribute Bases Access Control), it would be nice to define a "sub_id" able to support group memberships.
> For example, for an identifier supporting a group membership:
> 
> "sub_id": {
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event

---

From: Denis <[email-masked]>
Date: Wed, 17 Mar 2021 14:24:52 +0100

Hi  Justin,

Whether an access token content should be opaque or non-opaque to the 
client is still under debate today.
See an issue for GNAP: Opaque / Non opaque access token #145 
:https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145.

What GNAP will support or will not support is also under debate at this 
time. Nobody can tell today what GNAP is or is not.

The ideas expressed at the end of your email have not even been exposed 
or proposed to the GNAP WG at this time.
Exposing these proposals to the GNAP WG mailing list would more 
appropriate than exposing them to the ID-EVENT WG
mailing list.

Denis

>> In the GNAP WG, it is envisioned to request some /_types_ /of subject 
>> (with their values) into an access token and for a RS (Resources 
>> Server) to compare these subjects identifiers (with their values) 
>> against validation rules
>> originating from RO (Resource Owner) acting as an ADF (Access 
>> Decision Function) which also use the same subjects identifiers (with 
>> their values).
>>
>
> This is not accurate. In GNAP, there is functionality to request some 
> types of subject identifiers for the purpose of communicating them 
> directly to the client instance. GNAP does not prescribe a token 
> format, and does not specify any method of putting subject identifiers 
> into an access token, nor of communicating subject identifiers to the 
> RS for comparison or validation.
>
>  — Justin
>
>> On Mar 15, 2021, at 6:15 AM, Denis <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Last week, I sent to both of you two emails and since I got no 
>> response (your anti-spam software might be too effective), I have 
>> subscribed to the SECEVENT mailing list,
>>     A Subject Identifier is a JSON [RFC7159] object whose contents
>>     may be used to identify a subject */within some context/**.*
>>
>>       As described in Section 1.2 of SET [RFC8417], subjects
>>     */related to/**
>>     **/security events/* may take a variety of forms, including but not
>> These Subject Identifiers might still be used in a Security Event 
>> Token (SET) data structure, /but not necessarily/.
>>
>> **In the GNAP WG, it is envisioned to request some /_types_ /of 
>> subject identifiers to be placed into an access token, then to place 
>> some subjects identifiers
>> (with their values) into an access token and for a RS (Resources 
>> Server) to compare these subjects identifiers (with their values) 
>> against validation rules
>> originating from RO (Resource Owner) acting as an ADF (Access 
>> Decision Function) which also use the same subjects identifiers (with 
>> their values).
>>
>> More info is available in the slides 9 to 12 presented at the last 
>> IETF 110 GNAP WG virtual meeting. These slides are available at:
>> "id": "john_hughes.com <http://john_hughes.com>",
>> }
>>
>> When supporting ABAC (Attribute Bases Access Control), it would be 
>> nice to define a "sub_id" able to support group memberships.
>> [email-masked] <mailto:[email-masked]>