[Openid-specs-risc] Notes from call on 2021-03-02

[Atul Tulshibagwale]

Hi all,
Here are the notes from today's meeting. The notes are also captured in
this document
<https://docs.google.com/document/d/1ZFwJJDwwSBNKX35VObClC1ctMbMMuHJtr5qY-7xsLW8/edit?usp=sharing>.
Please provide your opinion on "Option A" versus "Option B" below.

Attendees:

   -

   Atul Tulshibagwale (Google)
   -

   Matt Domsch (SailPoint)
   -

   Annabelle Backman (AWS)
   -

   Tim Cappelli (Microsoft)
   -

   Peter Bjork (VMware)
   -

   Stan Bounev (VeriClouds)

Agenda:

   -

   Discussion on strings / GUIDs vs explicit subject identifiers (Tim)
   -

   AND processing text (Tim)
   -

   Goal of final draft by workshop in April? (Tim)
   -

   Feedback on “Compound Subject Types” proposal
   -

   Feedback on “Credentials Compromise” pull request.

Notes:

   -

   Annabelle: Not sure the “multi-valued” subject proposal is doing what it
   is supposed to
   -

   Annabelle: The claim “subject_type” should be renamed to “id_type”
   (after many examples of how subject claims are actually just ID claims)
   -

   On the call we agreed that we will have a “complex” or “compound”
   subject claim that can contain multiple subject-identifiers. In such a
   complex subject, the individual claim names would indicate the “category”
   that the identifier refers to, e.g. user, device, session, application.
   -

   On the call we agreed that instead of having subject-identifiers
   specific to “ou” or “tenant” as was proposed in the doc, we should perhaps
   add another subject-identifier type called “opaque-id”. This can be added
   to the SecEvents Subject Identifiers spec instead of in the SSE spec.
   -

   There was discussion on whether complex subjects should contain other
   “categories” such as “tenant”, “group” or “OU” claims. If they should,
   whether they should be separated from other categories such as “user”,
   “device”, etc.
   -

   Option A: would be to treat all claims within a complex subject to be at
   par, so a complex subject can have a “tenant” claim as well as a “user”
   claim. We can specify processing rules for specific claims. An example of a
   processing rule can be “if the recipient does not understand the tenant
   claim, then it must discard any event it receives that has such a tenant
   claim in it.”
   -

   Option B: would be to have two sub parts to a complex subject. One part
   (called say, category) will have claims such as “user”, “device”, “session”
   and “application”. The other part (called say, scope) will have claims such
   as “tenant”, “group” and “ou”. Even in Option B, we can have the same
   processing rules as described in Option A.
   -

   Atul (Google) and Tim (Microsoft) were both of the opinion to use Option
   A. Others have not provided an opinion, but Annabelle (AWS) is leaning
   toward Option B.

Clarifying Subject vs. Subject Identifier:

Q: What kind of principal is the subject of this JWT?

{

  "iss": "https://issuer.corp.example/",

  "sub": "11111111-1111-1111-1111-111111111111",

  "iat": "1614707025",

  "exp": "1614707625",

  "jti": "1234567890",

  "aud": "https://www.client.example/"

}

A: 🤷🏻‍♀️

Q: What kind of principal does this Subject Identifier refer to?

{

  "subject_type": "iss-sub",

  "iss": "https://issuer.corp.example/",

  "sub": "11111111-1111-1111-1111-11111111"

}

A: 🤷🏻‍♀️

Q: How about this one?

{

  "subject_type": "email",

  "email": "some.email at corp.example"

}

A: An email address

No! The email address is an identifier for the subject principal, not the
subject principal itself. The principal identified by an email address is
typically a user or account, but it doesn't have to be. In other words…

🤷🏻‍♀️

Subject != Subject Identifier

Subject Type != Subject Identifier Type

NOTE: The use of "subject_type" in Subject Identifiers is really confusing;
that property should be renamed "id_type".





Atul Tulshibagwale

Software Engineer,

Google Workspace

atultulshi at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20210302/bd99d026/attachment-0001.html>