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

[Justin Richer <[e-mail]>]

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 <[e-mail]> wrote:
> 
> Hello Annabelle and Marius,
> 
> 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, 
> 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, for an 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/ <http://server.com/>"
>      "id": "1452345734788822",
>      }
> 
> 
> For example, for a 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, for an 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, for an 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
> _______________________________________________
> Id-event mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/id-event