Subject: [Id-event] Review of draft-ietf-secevent-subject-identifiers-05

From: Dave Tonge <[email-masked]>
Date: Mon, 13 Jul 2020 07:15:06 +0200

Hi,

I'm really keen to see this draft progress and so have reviewed the current
text.

*Introduction*
I think it would be good to add some text to make it clear that while the
initial use case fo this spec is for SETs, there is nothing stopping it
being used in other contexts where parties need to communicate the identity
of a subject.For example we were looking at using this spec to have
structured a `login_hint` or `login_hint_token` in OIDC or CIBA flows.

*3.5.  Aliases Subject Identifier Type*
I definitely see this as a useful feature, however would it not be simpler
to define `sub_id` as an array, rather than have a specific "alias" type?

*Privacy Considerations*
Given that subject identifiers will often be personally identifiable
information, I think that there should be a sentence stating that if this
schema is used in any front-channel communication, then the token in which
the identifiers are embedded should be encrypted.

Thanks

-- 
Dave Tonge

-- 

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology 
Limited which is authorised and regulated by the Financial Conduct 
Authority ("FCA"). Moneyhub Financial Technology is entered on the 
Financial Services Register (FRN 809360) at https://register.fca.org.uk/ 
<https://register.fca.org.uk/>. Moneyhub Financial Technology is registered 
in England & Wales, company registration number 06909772. Moneyhub 
Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, 
Temple Quay, 1 Friary, Bristol, BS1 6EA. 

DISCLAIMER: This email 
(including any attachments) is subject to copyright, and the information in 
it is confidential. Use of this email or of any information in it other 
than by the addressee is unauthorised and unlawful. Whilst reasonable 
efforts are made to ensure that any attachments are virus-free, it is the 
recipient's sole responsibility to scan all attachments for viruses. All 
calls and emails to and from this company may be monitored and recorded for 
legitimate purposes relating to this company's business. Any opinions 
expressed in this email (or in any attachments) are those of the author and 
do not necessarily represent the opinions of Moneyhub Financial Technology 
Limited or of any other group company.

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 13 Jul 2020 20:07:27 +0000

Thanks for the review, Dave! Replies are [richanna] inline [/richanna].

–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/

From: Id-event <[email-masked]> on behalf of Dave Tonge <[email-masked]>
Date: Sunday, July 12, 2020 at 10:15 PM
To: SecEvent <[email-masked]>
Subject: [EXTERNAL] [Id-event] Review of draft-ietf-secevent-subject-identifiers-05

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

Hi,

I'm really keen to see this draft progress and so have reviewed the current text.

Introduction
I think it would be good to add some text to make it clear that while the initial use case fo this spec is for SETs, there is nothing stopping it being used in other contexts where parties need to communicate the identity of a subject.For example we were looking at using this spec to have structured a `login_hint` or `login_hint_token` in OIDC or CIBA flows.

[richanna]
Good suggestion. I think adding a couple examples of Subject Identifier usage would help too.
[/richanna]

3.5.  Aliases Subject Identifier Type
I definitely see this as a useful feature, however would it not be simpler to define `sub_id` as an array, rather than have a specific "alias" type?

[richanna]
Three reasons for “alias” as a formally defined type:

  1.  An array syntax for “sub_id” would allows us to specify multiple Subject Identifiers, but it wouldn’t define the semantics of that (i.e., they all refer to the same subject). We could define semantics, but that would only cover “sub_id”, and would have to be repeated by any spec that wants to use Subject Identifiers elsewhere.

  2.  An array syntax also forces everyone to deal with the additional complexity of what is likely to be a fairly niche use case. If we define “sub_id” as always being an array, we’ll likely end up with a bunch of nonconformant implementations that set it to a single Subject Identifier object because that’s their use case. If we make it an object or array, we’re in the world of polymorphic JSON which makes parsing a lot more complex.

  3.  The “alias” type leaves open the door for other ways to include multiple Subject Identifiers that have different semantics. For example, in the future someone may find it useful to define a “collection” type that contains a collection of Subject Identifiers referring to different entities.
[/richanna]

Privacy Considerations
Given that subject identifiers will often be personally identifiable information, I think that there should be a sentence stating that if this schema is used in any front-channel communication, then the token in which the identifiers are embedded should be encrypted.

[richanna]
This has been called out a few times now; it’s clear there is a need for this spec to explicitly call out these concerns, even if the guidance is just “fix this at another level.”
[/richanna]

Thanks

--
Dave Tonge

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.

DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.

---

From: Dave Tonge <[email-masked]>
Date: Tue, 14 Jul 2020 06:47:05 +0200

Thanks Annabelle

The explanation around the `alias` type is helpful and I agree with your
approach.

Dave

On Mon, 13 Jul 2020 at 22:07, Richard Backman, Annabelle <
[email-masked]> wrote:

> *From: *Id-event <[email-masked]> on behalf of Dave Tonge <
> [email-masked]>
> *Date: *Sunday, July 12, 2020 at 10:15 PM
> *To: *SecEvent <[email-masked]>
> *Subject: *[EXTERNAL] [Id-event] Review of
> draft-ietf-secevent-subject-identifiers-05
>
>
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> Hi,
>
>
>
>    1. An array syntax for “sub_id” would allows us to specify multiple
>    Subject Identifiers, but it wouldn’t define the semantics of that (i.e.,
>    they all refer to the same subject). We could define semantics, but that
>    would only cover “sub_id”, and would have to be repeated by any spec that
>    wants to use Subject Identifiers elsewhere.
>
>    2. An array syntax also forces everyone to deal with the additional
>    complexity of what is likely to be a fairly niche use case. If we define
>    “sub_id” as always being an array, we’ll likely end up with a bunch of
>    nonconformant implementations that set it to a single Subject Identifier
>    object because that’s their use case. If we make it an object or array,
>    we’re in the world of polymorphic JSON which makes parsing a lot more
>    complex.
>
>    3. The “alias” type leaves open the door for other ways to include
>    multiple Subject Identifiers that have different semantics. For example, in
>    the future someone may find it useful to define a “collection” type that
>    contains a collection of Subject Identifiers referring to different
>    entities.
>
> [/richanna]
>
>
>
> *Privacy Considerations*
>
> This has been called out a few times now; it’s clear there is a need for
> this spec to explicitly call out these concerns, even if the guidance is
> just “fix this at another level.”
>
> [/richanna]
>
>
>
> Thanks
>
>
>
> --
>
> *Dave Tonge*
>
>
>
>
>
> *Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
> Temple Quay, 1 Friary, Bristol, BS1 6EA. *
>
> DISCLAIMER: This email (including any attachments) is subject to
> copyright, and the information in it is confidential. Use of this email or
> of any information in it other than by the addressee is unauthorised and
> unlawful. Whilst reasonable efforts are made to ensure that any attachments
> are virus-free, it is the recipient's sole responsibility to scan all
> attachments for viruses. All calls and emails to and from this company may
> be monitored and recorded for legitimate purposes relating to this
> company's business. Any opinions expressed in this email (or in any
> attachments) are those of the author and do not necessarily represent the
> opinions of Moneyhub Financial Technology Limited or of any other group
> company.
>
>
>

-- 
Dave Tonge
CTO
<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Moneyhub Financial Technology is entered on the
Financial Services Register (FRN 809360) at fca.org.uk/register.
Moneyhub Financial
Technology is registered in England & Wales, company registration number
06909772 .
Moneyhub Financial Technology Limited 2018 ©

DISCLAIMER: This email (including any attachments) is subject to copyright,
and the information in it is confidential. Use of this email or of any
information in it other than by the addressee is unauthorised and unlawful.
Whilst reasonable efforts are made to ensure that any attachments are
virus-free, it is the recipient's sole responsibility to scan all
attachments for viruses. All calls and emails to and from this company may
be monitored and recorded for legitimate purposes relating to this
company's business. Any opinions expressed in this email (or in any
attachments) are those of the author and do not necessarily represent the
opinions of Moneyhub Financial Technology Limited or of any other group
company.

-- 

DISCLAIMER: This email