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

[Denis <[e-mail]>]

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: "[e-mail]" <mailto:[e-mail]>,
}

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