Subject: Re: [Txauth] Questions on the TxAuth charter

From: Justin Richer <[email-masked]>
Date: Tue, 28 Jan 2020 12:28:44 +0100

Hi Kim, thanks for the feedback. Answers inline, below.

> On Jan 28, 2020, at 1:57 AM, Kim <[email-masked]> wrote:
> 
> Dear Justin,
> 
> The current wording of the draft charter raised questions for me that others might share. Clarifying these would help those of us not familiar with the work to date.
> 
> > This group is chartered to develop a delegation protocol for authorization, identity, and API access.
> 
> Can you please expand on what you mean by delegation of identity and whether that leverages claims and tokens as defined in OpenID Connect?
> 

We would not necessarily be using the exact claims and mechanisms in OIDC.

> > The use cases supported by this protocol will include widely deployed use cases currently supported by OAuth 2.0 and OpenID Connect (an extension of OAuth 2.0) as well as new use cases not enabled by OAuth 2.0.
> 
> I understand and support the motivations to rework the authorization flows.  However, the identity representations in OpenID Connect have already shown themselves to work well in conveying the identity of the end user. It seems prudent to avoid the confusion and complexity that would result from introducing new mechanisms to do the same thing. Will the enhancements to the authorization leverage what already works and has become a unifying technology?
> 

And when OIDC was invented, SAML had already been shown to work well in conveying the identity of an end user. I believe we can make a similar leap forward here. This is not just a new conveyance mechanism for OIDC, but it will certainly learn from it as OIDC learned from SAML and other things that came before.

> > This protocol will allow an authorizing party to delegate access to client software through an authorization server… 
> 
> > The client and AS will involve the authorizing party as necessary through interaction mechanisms indicated by the protocol. 
> 
> What is the authorizing party? Is that one of the roles in the protocol?  Is it the end user?
> 

It’s the OAuth/UMA “Resource Owner”, which might be the user using the client software and might be someone else that the AS can contact through other means. 

> > Approval of AS attestation to identity claims
> 
> Does this mean that the AS is approving of the claims and conveying that approval to another party (and what party would that be)? 
> 
No, the authorizing party is approving the claims and the AS is conveying the identity claims and the delegated access token to the client. 

> By identity claims are you leveraging claims as defined in OpenID Connect?
> 

Not necessarily, but they’re on the table as items to consider.

> Are the identity claims about the end user – or other subjects as well?
> 

Generally speaking yes, though in the multi-user case (CIBA, UMA, and some device-flow use cases today), the claims of the authorizing party are being conveyed to the end user of the client, who might be a different party. This is an advanced use case, though, so I see it as something we can enable but not likely to be the most common use case, which is conveying the current user’s claims to a piece of software that they’re using.

> > Mechanisms for providing user, software, organization, and other pieces of information used in authorization decisions – 
> 
> Could you elaborate on what information about users would be supplemental to those expressed as claims?  Also, would information about software and organization be expressed as claims? 
> 

How the user logged in today, how the user was proofed when they got the account, the status of the client software that was making the request at the time, etc. So yes, software and organization could also be represented as claims, though I can also imagine those being in different data structures. 
> > Optimization of information and API access beyond identity through the delegation process
> 
> Could you please explain what is meant by this goal and how it relates to identity?
> 

At its core this isn’t an identity protocol, but a delegation protocol. One of the core things that it can delegate is knowledge of the identity of the user. This is how OIDC is built on top of OAuth 2, and we’re looking at repeating that kind of layering but in a more direct way as possible.

 — Justin

> Thanks!
> 
> Kim Cameron
> 
>  
> 
>  
> 
> -- 
> Txauth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 28 Jan 2020 08:11:58 -0800

Kim: are you suggesting that supporting OIDC claims be in the charter?

While I think that supporting OIDC claims is desirable, I don't think that
belongs in the charter.

Justin: OIDC claims inherently had to be different from SAML as the syntax
was JSON vs XML.

Are you suggesting that a different document format be used than JSON?

What do you see as lacking in the OIDC claims?

On Tue, Jan 28, 2020 at 3:30 AM Justin Richer <[email-masked]> wrote:

> The current wording of the draft charter raised questions for me that
> others might share. Clarifying these would help those of us not familiar
> with the work to date.
>
> Can you please expand on what you mean by delegation of identity and
> whether that leverages claims and tokens as defined in OpenID Connect?
>
>
> > The use cases supported by this protocol will include widely deployed
> use cases currently supported by OAuth 2.0 and OpenID Connect (an extension
> of OAuth 2.0) as well as new use cases not enabled by OAuth 2.0.
>
> I understand and support the motivations to rework the authorization
> flows.  However, the identity representations in OpenID Connect have
> already shown themselves to work well in conveying the identity of the end
> user. It seems prudent to avoid the confusion and complexity that would
> result from introducing new mechanisms to do the same thing. Will the
> enhancements to the authorization leverage what already works and has
> become a unifying technology?
>
>
> And when OIDC was invented, SAML had already been shown to work well in
> conveying the identity of an end user. I believe we can make a similar leap
> forward here. This is not just a new conveyance mechanism for OIDC, but it
> will certainly learn from it as OIDC learned from SAML and other things
> that came before.
>
> > This protocol will allow an authorizing party to delegate access to
> client software through an authorization server…
>
> > The client and AS will involve the authorizing party as necessary
> through interaction mechanisms indicated by the protocol.
>
> It’s the OAuth/UMA “Resource Owner”, which might be the user using the
> client software and might be someone else that the AS can contact through
> other means.
>
> Does this mean that the AS is approving of the claims and conveying that
> approval to another party (and what party would that be)?
>
> No, the authorizing party is approving the claims and the AS is conveying
> the identity claims and the delegated access token to the client.
>
> Generally speaking yes, though in the multi-user case (CIBA, UMA, and some
> device-flow use cases today), the claims of the authorizing party are being
> conveyed to the end user of the client, who might be a different party.
> This is an advanced use case, though, so I see it as something we can
> enable but not likely to be the most common use case, which is conveying
> the current user’s claims to a piece of software that they’re using.
>
> > Mechanisms for providing user, software, organization, and other pieces
> of information used in authorization decisions –
>
> Could you elaborate on what information about users would be supplemental
> to those expressed as claims?  Also, would information about software and
> organization be expressed as claims?
>
>
> How the user logged in today, how the user was proofed when they got the
> account, the status of the client software that was making the request at
> the time, etc. So yes, software and organization could also be represented
> as claims, though I can also imagine those being in different data
> structures.
>
> At its core this isn’t an identity protocol, but a delegation protocol.
> One of the core things that it can delegate is knowledge of the identity of
> the user. This is how OIDC is built on top of OAuth 2, and we’re looking at
> repeating that kind of layering but in a more direct way as possible.
>
>  — Justin
>
> Thanks!
>
> Kim Cameron
>
>
>
>
> --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>
>
> --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 28 Jan 2020 17:57:24 +0100

The claims in OIDC aren’t just JSON, many of them are JWT payload elements, which need to be compact so that it could fit better into browser redirects and places like that. I contend that we are not bound by the same restrictions, so just like with the SAML translations of “<saml:Issuer>” to “iss” we should consider what we really need in the new space even if it’s the same concepts translated over.

We’d be foolish to ignore them, but also nearly as foolish to take them just because they exist and it’s the world we know. For instance, we know that the OIDC separation of issuer and subject into a pair of values is really confusing to developers and leads to people using email address, username, or other incorrect fields as a universal identifier. There are some things that we got right, though, such as the flat namespace-less JSON data model that allows domain extensions.

So just as with anything else in this proposed new work, I am arguing that we should take OIDC claims as an influencing input to be evaluated in the context of what we’re trying to do. “We did it this way in OIDC” is not a sufficient argument for its inclusion in TxAuth, and therefore I agree that it does not belong anywhere in the charter. But we also need to look at what we did do in OIDC and figure out how and if it fits as we’re figuring out solutions.

 — Justin

> On Jan 28, 2020, at 5:11 PM, Dick Hardt <[email-masked]> wrote:
> 
> While I think that supporting OIDC claims is desirable, I don't think that belongs in the charter.
> 
> Justin: OIDC claims inherently had to be different from SAML as the syntax was JSON vs XML.
> 
> On Tue, Jan 28, 2020 at 3:30 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jan 28, 2020, at 1:57 AM, Kim <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Dear Justin,
>>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 28 Jan 2020 17:00:14 +0000

OIDC claims got a lot right, but they aren’t perfect. Here are a few issues with them:

  *   The only defined values for gender are male and female.
  *   The ..._name claims encourage designs that cater to Western naming conventions.
  *   The ..._verified claims don’t define how or when verification occurred.
  *   Poor support for multiple email addresses or phone numbers.
  *   No mechanism for specifying a required value for part of a complex claim (e.g., requiring an address in a particular country).
  *   The picture claim is unnecessarily constrained to be a photo of the end user.
  *   The semantic difference between a claim about a subject and resources owned by a subject is lost on developers, leading to custom claims that don’t really make sense as claims.

On Jan 28, 2020, at 8:12 AM, Dick Hardt <[email-masked]> wrote:

---

From: Dick Hardt <[email-masked]>
Date: Tue, 28 Jan 2020 09:05:11 -0800

Agreed.

Not having subject be a globally unique identifier, nor defining a
concatenation mechanism  has been a developer issue.

On Tue, Jan 28, 2020 at 8:57 AM Justin Richer <[email-masked]> wrote:

> The claims in OIDC aren’t just JSON, many of them are JWT payload
> elements, which need to be compact so that it could fit better into browser
> redirects and places like that. I contend that we are not bound by the same
> restrictions, so just like with the SAML translations of “<saml:Issuer>” to
> “iss” we should consider what we really need in the new space even if it’s
> the same concepts translated over.
>
> We’d be foolish to ignore them, but also nearly as foolish to take them
> just because they exist and it’s the world we know. For instance, we know
> that the OIDC separation of issuer and subject into a pair of values is
> really confusing to developers and leads to people using email address,
> username, or other incorrect fields as a universal identifier. There are
> some things that we got right, though, such as the flat namespace-less JSON
> data model that allows domain extensions.
>
> So just as with anything else in this proposed new work, I am arguing that
> we should take OIDC claims as an influencing input to be evaluated in the
> context of what we’re trying to do. “We did it this way in OIDC” is not a
> sufficient argument for its inclusion in TxAuth, and therefore I agree that
> it does not belong anywhere in the charter. But we also need to look at
> what we did do in OIDC and figure out how and if it fits as we’re figuring
> out solutions.
>
>  — Justin
>
>> Generally speaking yes, though in the multi-user case (CIBA, UMA, and
>> some device-flow use cases today), the claims of the authorizing party are
>> being conveyed to the end user of the client, who might be a different
>> party. This is an advanced use case, though, so I see it as something we
>> can enable but not likely to be the most common use case, which is
>> conveying the current user’s claims to a piece of software that they’re
>> using.
>>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 28 Jan 2020 09:11:10 -0800

Thanks Annabelle. Schema has always been difficult in identity. We can get
it more right this time, but I think the right extensibility is important
to enable continual improvement.

Comments inserted ...

On Tue, Jan 28, 2020 at 9:00 AM Richard Backman, Annabelle <
[email-masked]> wrote:

>    - The only defined values for gender are male and female.
>
> agreed — in fairness the awareness is much greater now

>
>    -
>    - The ..._name claims encourage designs that cater to Western naming
>    conventions.
>
> agreed

>
>    -
>    - The ..._verified claims don’t define how or when verification
>    occurred.
>
> agreed

>
>    -
>    - Poor support for multiple email addresses or phone numbers.
>
> has this been an issue?

>
>    -
>    - No mechanism for specifying a required value for part of a complex
>    claim (e.g., requiring an address in a particular country).
>
> interesting

>
>    -
>    - The picture claim is unnecessarily constrained to be a photo of the
>    end user.
>
> agreed

>
>    -
>    - The semantic difference between a claim about a subject and
>    resources owned by a subject is lost on developers, leading to custom
>    claims that don’t really make sense as claims.
>
> would you elaborate or provide examples?

>    -

---

From: Justin Richer <[email-masked]>
Date: Tue, 28 Jan 2020 18:32:51 +0100

I think “getting it more right” is exactly the goal. OIDC’s schema is a much better starting point than SAMLs was, but a starting point is not where we stop!

 — Justin

> On Jan 28, 2020, at 6:11 PM, Dick Hardt <[email-masked]> wrote:
> 
> Thanks Annabelle. Schema has always been difficult in identity. We can get it more right this time, but I think the right extensibility is important to enable continual improvement.
> 
> Comments inserted ...
> 
> On Tue, Jan 28, 2020 at 9:00 AM Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
> The only defined values for gender are male and female.
> The ..._name claims encourage designs that cater to Western naming conventions.
> agreed
> The ..._verified claims don’t define how or when verification occurred.
> agreed
> Poor support for multiple email addresses or phone numbers.
> has this been an issue?
> No mechanism for specifying a required value for part of a complex claim (e.g., requiring an address in a particular country).
> interesting
> The picture claim is unnecessarily constrained to be a photo of the end user.
> agreed
> The semantic difference between a claim about a subject and resources owned by a subject is lost on developers, leading to custom claims that don’t really make sense as claims.
>> On Jan 28, 2020, at 8:12 AM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 28 Jan 2020 19:47:41 +0000

Regarding multiple email addresses or phone numbers (or addresses, which I left out in my earlier email), there are cases where people are asked to provide multiple phone numbers or email addresses (e.g., patient intake forms). With OIDC, you’d have to define separate claims (e.g., mobile_phone, office_phone) and of course it’s not clear how just plain “phone_number” would fit in with that. Even if all the client wants is one value, it can be helpful to know which one (e.g., a mobile app needs a mobile phone number, not a landline; a digital music store needs a billing address, but not a shipping address).

Regarding claims vs. resources, I’ve seen developers want to use claims as a bucket for including data related to scopes in authentication requests, when what they really needed was RAR or something like it. For Login with Amazon, we added a proprietary “scope_data” parameter (since RAR didn’t exist at the time). On the reverse end, I’ve seen developers want to add various resources as claims in order to optimize the client experience. Why should we make the client do another round trip if we already know what they will ask for and what we’ll return? This comes up particularly in situations where the end user is authorizing a specific operation (e.g., a single payment, retrieval of a specific image/document).

–
Annabelle Richard Backman
AWS Identity

From: Dick Hardt <[email-masked]>
Date: Tuesday, January 28, 2020 at 9:12 AM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: Justin Richer <[email-masked]>, Kim <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Txauth] Questions on the TxAuth charter

Comments inserted ...

On Tue, Jan 28, 2020 at 9:00 AM Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:
OIDC claims got a lot right, but they aren’t perfect. Here are a few issues with them:

  *

  *

  *

  *

  *

  *

  *
On Jan 28, 2020, at 8:12 AM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
What do you see as lacking in the OIDC claims?

---

From: Dick Hardt <[email-masked]>
Date: Tue, 28 Jan 2020 12:35:24 -0800

On Tue, Jan 28, 2020 at 11:47 AM Richard Backman, Annabelle <
[email-masked]> wrote:

> Regarding multiple email addresses or phone numbers (or addresses, which I
> left out in my earlier email), there are cases where people are asked to
> provide multiple phone numbers or email addresses (e.g., patient intake
> forms). With OIDC, you’d have to define separate claims (e.g.,
> mobile_phone, office_phone) and of course it’s not clear how just plain
> “phone_number” would fit in with that. Even if all the client wants is one
> value, it can be helpful to know which one (e.g., a mobile app needs a
> mobile phone number, not a landline; a digital music store needs a billing
> address, but not a shipping address).
>

I've viewed the value of unverified claims is making it easier for a user
form fill at Client. There will often be additional information the Client
needs that is fairly Client specific.
I worry about the extra complexity that supporting multiple
email/phone/address would add to the developer of the AS and the Client, as
well as the extra UX for a User to understand at an AS, for an infrequent
use case. Additionally, in the consumer space, most OIDC providers usually
only have one email or phone.

>
>
> Regarding claims vs. resources, I’ve seen developers want to use claims as
> a bucket for including data related to scopes in authentication requests,
> when what they really needed was RAR or something like it. For Login with
> Amazon, we added a proprietary “scope_data” parameter (since RAR didn’t
> exist at the time).
>

Sorry, I still don't understand this use case.

> On the reverse end, I’ve seen developers want to add various resources as
> claims in order to optimize the client experience.
>

For example? Is what you are describing what is below?

> Why should we make the client do another round trip if we already know
> what they will ask for and what we’ll return? This comes up particularly in
> situations where the end user is authorizing a specific operation (e.g., a
> single payment, retrieval of a specific image/document).
>

Is this covered by RAR?

> *From: *Dick Hardt <[email-masked]>
> *Date: *Tuesday, January 28, 2020 at 9:12 AM
> *To: *"Richard Backman, Annabelle" <[email-masked]>
> *Cc: *Justin Richer <[email-masked]>, Kim <[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Subject: *Re: [Txauth] Questions on the TxAuth charter
>
>
>
> ᐧ

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 29 Jan 2020 06:13:39 +0100

> Am 28.01.2020 um 18:00 schrieb Richard Backman, Annabelle <richanna=[email-masked]>:
> 

Sure, they do. Look at the time and method fields. 

Since OpenId Connect for Identity Assurance (aka verified_claims) is ongoing work feel free to contribute.

https://openid.net/wg/ekyc-ida/

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 29 Jan 2020 06:16:01 +0100

> Am 28.01.2020 um 18:05 schrieb Dick Hardt <[email-masked]>:
> 
> 
> Agreed.
> 
> Not having subject be a globally unique identifier, nor defining a concatenation mechanism  has been a developer issue.

Do you really think that is the reason people use email addresses?

BTW: I have even seen OPs using phone numbers (or hashes thereof) as sub values. I think that’s an issue with knowledge/education.
>>>>> I understand and support the motivations to rework the authorization flows..  However, the identity representations in OpenID Connect have already shown themselves to work well in conveying the identity of the end user. It seems prudent to avoid the confusion and complexity that would result from introducing new mechanisms to do the same thing. Will the enhancements to the authorization leverage what already works and has become a unifying technology?
>>>>> 
>>>> 
>>>> It’s the OAuth/UMA “Resource Owner”, which might be the user using the client software and might be someone else that the AS can contact through other means.. 
>>>>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 28 Jan 2020 21:57:20 -0800

> Do you really think that is the reason people use email addresses?

I have heard that from a number of product PMs.

Email has its own desirable features, but is a poor identifier as it makes
it harder to change. Most sophisticated implementations  have some private
key, and the id_token ids index to it.

> BTW: I have even seen OPs using phone numbers (or hashes thereof) as sub
> values. I think that’s an issue with knowledge/education.
>
>
>> So just as with anything else in this proposed new work, I am arguing
>> that we should take OIDC claims as an influencing input to be evaluated in
>> the context of what we’re trying to do. “We did it this way in OIDC” is not
>> a sufficient argument for its inclusion in TxAuth, and therefore I agree
>> that it does not belong anywhere in the charter. But we also need to look
>> at what we did do in OIDC and figure out how and if it fits as we’re
>> figuring out solutions.
>>
>>  — Justin
>>
>>> flows..  However, the identity representations in OpenID Connect have
>>> other means..
>>> No, the authorizing party is approving the claims and the AS is
>>> conveying the identity claims and the delegated access token to the client.
>>>
>>> > Mechanisms for providing user, software, organization, and other
>>> pieces of information used in authorization decisions –
>>>
>>> Could you elaborate on what information about users would be
>>> supplemental to those expressed as claims?  Also, would information about
>>> software and organization be expressed as claims?
>>>
>>>

---

From: Justin Richer <[email-masked]>
Date: Wed, 29 Jan 2020 07:33:56 +0100

I think the ekyc work is great for what it is, but again we have an opportunity to take a step beyond it. In my view, we’d be better off defining a means of specifying field metadata a la NIST IR 8112 as part of the schema instead of patching the existing OIDC fields. https://pages.nist.gov/NISTIR-8112/

 — Justin

> On Jan 29, 2020, at 6:13 AM, Torsten Lodderstedt <[email-masked]> wrote:
> 
> 
> 
> https://openid.net/wg/ekyc-ida/ <https://openid.net/wg/ekyc-ida/>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 29 Jan 2020 08:06:24 +0100

> Am 29.01.2020 um 07:34 schrieb Justin Richer <[email-masked]>:
> 

We tried and it did not fulfill our requirements. verified_claims is by no means a patch, it’s a viable solution.

---

From: Justin Richer <[email-masked]>
Date: Wed, 29 Jan 2020 09:46:20 +0100

I didn’t mean “patch” to sound disparaging, sorry if it came across as such. What I mean by “patching” here is that it is adding functionality to an existing set of claims and schema. If you are using that schema as a base, it makes sense as a viable solution in that space. I, however, am bringing up the question of whether we are using that schema as our base at all.

I’ll note that 8112 doesn’t define a schema or syntax, both of which are required. But if we were starting OIDC today with EKYC’s requirements, I’m not convinced we’d end up with the same structure. 

As with everything, it’s a very important input into what we’re trying to solve, especially influencing what’s extensible and how.

 — Justin

> On Jan 29, 2020, at 8:06 AM, Torsten Lodderstedt <[email-masked]> wrote:
> 
> 
> 
>> I think the ekyc work is great for what it is, but again we have an opportunity to take a step beyond it. In my view, we’d be better off defining a means of specifying field metadata a la NIST IR 8112 as part of the schema instead of patching the existing OIDC fields. https://pages.nist.gov/NISTIR-8112/ <https://pages.nist.gov/NISTIR-8112/>
>>> On Jan 29, 2020, at 6:13 AM, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
>>> 
>>>> Am 28.01.2020 um 18:00 schrieb Richard Backman, Annabelle <richanna=[email-masked] <mailto:richanna=[email-masked]>>:
>>>>

---

From: Mike Jones <[email-masked]>
Date: Wed, 29 Jan 2020 08:50:22 +0000

Thanks for writing these detailed questions, Kim.  I believe that they point out a number of places where even experts in the field, such as yourself, currently have trouble understanding parts of what the charter is proposing that we do – partially because terminology is used that isn’t commonly understood.  I hope that the draft charter will be revised to make the intent and the goals more accessible and less ambiguous.

Responding to the discussion on whether existing JWT identity claims will do the job or not, fortunately, even if they don’t, there’s a mechanism to add ones that do: the IANA JSON Web Token Claims registry at https://www.iana.org/assignments/jwt/jwt.xhtml#claims.  For instance, an “email_addresses” claim that is array-valued could be defined and registered if there’s a need to represent multiple e-mail addresses, per Annabelle’s example.  The further good news is that if the working group defines new claims that are registered, they can be reused by others also using JWTs – just like this working group can reuse claims defined by others.

Also on the subject of JWTs, I would suggest that the charter be updated to explicitly call out that JWTs will be the working group’s preferred representation signed and/or encrypted claims.

Finally, I also think that the charter would benefit from explicitly listing things that are out of scope (which is often done in charters).

Thanks again for prompting this useful discussion, Kim.

                                                       -- Mike

From: Txauth <[email-masked]> On Behalf Of Justin Richer
Sent: Wednesday, January 29, 2020 12:46 AM
To: Torsten Lodderstedt <[email-masked]>
Cc: Kim <[email-masked]>; Dick Hardt <[email-masked]>; [email-masked]; Richard Backman, Annabelle <richanna=[email-masked]>
Subject: [EXTERNAL] Re: [Txauth] Questions on the TxAuth charter

 — Justin

On Jan 29, 2020, at 8:06 AM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:

Am 29.01.2020 um 07:34 schrieb Justin Richer <[email-masked]<mailto:[email-masked]>>:
I think the ekyc work is great for what it is, but again we have an opportunity to take a step beyond it. In my view, we’d be better off defining a means of specifying field metadata a la NIST IR 8112 as part of the schema instead of patching the existing OIDC fields. https://pages.nist.gov/NISTIR-8112/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpages.nist.gov%2FNISTIR-8112%2F&data=02%7C01%7CMichael.Jones%40microsoft.com%7C9fae503669f443a0968308d7a497c45f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158844049338344&sdata=rOrKaO7MvDDKLyfB2QivbVTcj5EmRSJ1nRXXs30jEz0%3D&reserved=0>

 — Justin

On Jan 29, 2020, at 6:13 AM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:

Am 28.01.2020 um 18:00 schrieb Richard Backman, Annabelle <richanna=[email-masked]<mailto:richanna=[email-masked]>>:
The ..._verified claims don’t define how or when verification occurred.

https://openid.net/wg/ekyc-ida/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fwg%2Fekyc-ida%2F&data=02%7C01%7CMichael.Jones%40microsoft.com%7C9fae503669f443a0968308d7a497c45f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158844049338344&sdata=pg8upwyN%2BXKeaFZaKEvR%2BTEPsKgjeJtdHwPM1fe%2Fxnc%3D&reserved=0>

---

From: Justin Richer <[email-masked]>
Date: Wed, 29 Jan 2020 10:05:44 +0100

I strongly object to calling out JWTs as the preferred solution for signed and encrypted claims within this working group.

 — Justin

> On Jan 29, 2020, at 9:50 AM, Mike Jones <[email-masked]> wrote:
> 
> Responding to the discussion on whether existing JWT identity claims will do the job or not, fortunately, even if they don’t, there’s a mechanism to add ones that do: the IANA JSON Web Token Claims registry at https://www.iana.org/assignments/jwt/jwt.xhtml#claims <https://www.iana.org/assignments/jwt/jwt.xhtml#claims>.  For instance, an “email_addresses” claim that is array-valued could be defined and registered if there’s a need to represent multiple e-mail addresses, per Annabelle’s example.  The further good news is that if the working group defines new claims that are registered, they can be reused by others also using JWTs – just like this working group can reuse claims defined by others.
>  
> From: Txauth <[email-masked] <mailto:[email-masked]>> On Behalf Of Justin Richer
> To: Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>>
> Cc: Kim <[email-masked] <mailto:[email-masked]>>; Dick Hardt <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Richard Backman, Annabelle <richanna=[email-masked] <mailto:richanna=[email-masked]>>
> On Jan 29, 2020, at 8:06 AM, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
>  
>  
> 
> 
> Am 29.01.2020 um 07:34 schrieb Justin Richer <[email-masked] <mailto:[email-masked]>>:
> 
> I think the ekyc work is great for what it is, but again we have an opportunity to take a step beyond it. In my view, we’d be better off defining a means of specifying field metadata a la NIST IR 8112 as part of the schema instead of patching the existing OIDC fields. https://pages.nist.gov/NISTIR-8112/ <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpages.nist.gov%2FNISTIR-8112%2F&data=02%7C01%7CMichael.Jones%40microsoft.com%7C9fae503669f443a0968308d7a497c45f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158844049338344&sdata=rOrKaO7MvDDKLyfB2QivbVTcj5EmRSJ1nRXXs30jEz0%3D&reserved=0>
>  
> https://openid.net/wg/ekyc-ida/ <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fwg%2Fekyc-ida%2F&data=02%7C01%7CMichael.Jones%40microsoft.com%7C9fae503669f443a0968308d7a497c45f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158844049338344&sdata=pg8upwyN%2BXKeaFZaKEvR%2BTEPsKgjeJtdHwPM1fe%2Fxnc%3D&reserved=0>

---

From: Justin Richer <[email-masked]>
Date: Wed, 29 Jan 2020 12:36:27 +0100

I got a chance to chat with Mike and I wanted to expand my off-the-cuff response (below) with some more detail than I was able to write in the moment, because I don’t think that we’re actually that far apart. 

To start, it wasn’t obvious to me (and might not have been to others) the specific precision of Mike’s statement below. He clarified to me that what he means is that where user claims are signed or encrypted, then JWT provides an obvious way to do it. In other words, “don’t re-invent the ID Token with new crypto”. There are several things to address here with that in mind.

First, I don’t believe there are going to be many, if any, cases where we need user claims to be signed and encrypted separately from the core transaction messages. Even in OIDC, the ID Token is allowed to be unsigned when it is retrieved from the token endpoint directly using the code flow. The equivalent of this is the only place that TxAuth would be sending back user claims directly. We no longer have a need to protect things as they travel through the front channel on a redirect, and we no longer have a need to use the user’s claims as an artifact for things like session management (we can define a new artifact for that purpose that fits better). This effectively means that we don’t need to redefine the ID Token because we don’t need the equivalent of the ID token in the same way. For the cases that we do need to define user claims, we should be defining them as a JSON object model. And I also believe that this JSON data model should not be intertwined with or constrained by the JWT claims registry. The OIDC claims registry can serve as influence and input to our user claims set if we choose, but I don’t think we should be intertwined with that either.

Second, in spite of the success of OIDC, there are several formats out there for user claims beyond JWT and JOSE. Verifiable Credentials (VC, https://www.w3.org/TR/vc-data-model/) is one that has several different formats, and we are also seeing systems built up around COSE and CBOR (like IPLD, https://ipld.io/). Or you could even use a SAML document. I don’t think TxAuth should pick just one of these. Instead, I want TxAuth to define places to put these formats in requests and responses. In my draft there’s a spot for an OIDC style ID Token or a VC document, if you have one. Within each of these, by all means, let’s lock them down and say that the “oidc_id_token” field is a JWT in compact format that MUST be signed, etc. And I think it makes little sense to invent our own custom format to do exactly that kind of thing. 

Third, I agree that we shouldn’t re-invent an existing crypto format, and I’ll go further that we shouldn’t be inventing crypto at all. This doesn’t mean we have to pick one and only one, because this is one of the spaces that we can (and I argue should) have some agility. We can define the protocol in terms of JSON and then have a suite of cryptographic carriers that protect that JSON, including JOSE, HTTP Message Signatures, and Mutual TLS. There are a bunch of others out there as well, like the DPoP key presentation coming out of OAuth 2 right now, that should be switchable as options here because they’re going to apply to different use cases and deployments. Plus, that JSON could be translated to CBOR (without data or structure loss) and protected by COSE — even if we don’t define that ourselves, the fact that we’re building our structure on raw JSON means that it can be translated more easily later.

Fourth, I am very sensitive to calling out preferred crypto solutions because I believe that lends to us using that as an excuse to use that particular hammer to solve all the problems. There have been proposals to make the entire protocol JWTs in all directions, for instance, that I think are really problematic because of the limits that it places on expression of items outside of the payload itself. This is not what Mike is suggesting below, but it’s a potential fallout from what he does propose.

In conclusion, JOSE and JWT are fantastic and they solve a lot of problems in an elegant way. But I think we need to question whether we need their solutions at all, and where we do, if we want to enable other solutions as well. In my view, we don’t need JOSE/JWT because we avoid the problems that they solve, and the places that we do want to use them I strongly believe there are already other alternatives that we want to have as options. 

So I want to have JOSE, but it needs to be in the right places and I do not want it to be a dependency on all implementations. I think that we can do that without saying JWT is a preferred format. I think it’s more important that the charter incorporate specific text of what’s out of scope, including defining a cryptographic protection mechanism. 

One of the hardest things for a standard to do is determine where the flexibility should be. My stance is that we should have a structural format based on JSON but that the contents of that JSON are extensible but that each portion and extension are very strict about what’s there. Another key flexible point is that the content of the JSON-based payloads can be protected in a variety of ways. Choice can be debilitating, but it can also be freeing. Pinning everything to JOSE would do us a disservice. 

 — Justin

> On Jan 29, 2020, at 10:05 AM, Justin Richer <[email-masked]> wrote:
> 
>> On Jan 29, 2020, at 9:50 AM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 29 Jan 2020 18:48:52 +0000

I was referring to the email_verified and phone_number_verified claims defined in OIDC Core. The mechanisms defined in IA don’t appear to apply to those claims. Am I missing something?

(I do have some feedback regarding claims in IA…getting on the IA working group list and providing it is on my far-too-long todo list…)
–
Annabelle Richard Backman
AWS Identity

From: Txauth <[email-masked]> on behalf of Torsten Lodderstedt <torsten=[email-masked]>
Date: Tuesday, January 28, 2020 at 9:13 PM
To: "Richard Backman, Annabelle" <richanna=[email-masked]>
Cc: Kim <[email-masked]>, "[email-masked]" <[email-masked]>, Justin Richer <[email-masked]>, Dick Hardt <[email-masked]>
Subject: Re: [Txauth] Questions on the TxAuth charter

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 29 Jan 2020 20:45:27 +0100

> Am 29.01.2020 um 19:49 schrieb Richard Backman, Annabelle <richanna=[email-masked]>:
> 
> 

Those claims pre-date OIDC4IDA. If they do not suite your needs, you may use verified_claims to represent the verification status. It requires a trust framework id determining the trust framework governing the verification along with identifiers for verification methods etc.

> (I do have some feedback regarding claims in IA…getting on the IA working group list and providing it is on my far-too-long todo list…)

look forward to getting your feedback.

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 29 Jan 2020 20:15:18 +0000

I am well aware of the fact that OIDC Core predates ODC4IDA, and that the claims I am referring to are defined in the former, as noted in my previous message. Telling me to use verified_claims is not helpful when I’ve already stated that I have looked at that spec and it does not appear to address my use case. I’d appreciate less condescension and more attention to message content, thanks.

–

From: Torsten Lodderstedt <torsten=[email-masked]>
Date: Wednesday, January 29, 2020 at 11:45 AM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: Kim <[email-masked]>, "[email-masked]" <[email-masked]>, Justin Richer <[email-masked]>, Dick Hardt <[email-masked]>
Subject: [UNVERIFIED SENDER] Re: [Txauth] Questions on the TxAuth charter

–

---

From: Dick Hardt <[email-masked]>
Date: Wed, 29 Jan 2020 12:49:55 -0800

I agree with Justin that we choose JSON for the messages, but that we have
flexibility in how to secure the messages, and flexibility in the claim
formats that can be requested and returned. In contrast, we don't want to
dictate JOSE for messages or JWT for claims.

Justin gave me the feedback in earlier drafts of XAuth, and I (hopefully)
factored out the JOSE aspects so that HTTP signing, MTLS, or something else
could be used.

I disagree with Justin's first point about the need for signed claims. I'll
start another thread for that, as it is not relevant to this thread's
charter discussion.

/Dick

On Wed, Jan 29, 2020 at 3:37 AM Justin Richer <[email-masked]> wrote:

> I got a chance to chat with Mike and I wanted to expand my off-the-cuff
> response (below) with some more detail than I was able to write in the
> moment, because I don’t think that we’re actually that far apart.
>
> To start, it wasn’t obvious to me (and might not have been to others) the
> specific precision of Mike’s statement below. He clarified to me that what
> he means is that where user claims are signed or encrypted, then JWT
> provides an obvious way to do it. In other words, “don’t re-invent the ID
> Token with new crypto”. There are several things to address here with that
> in mind.
>
> First, I don’t believe there are going to be many, if any, cases where we
> need user claims to be signed and encrypted separately from the core
> transaction messages. Even in OIDC, the ID Token is allowed to be unsigned
> when it is retrieved from the token endpoint directly using the code flow.
> The equivalent of this is the only place that TxAuth would be sending back
> user claims directly. We no longer have a need to protect things as they
> travel through the front channel on a redirect, and we no longer have a
> need to use the user’s claims as an artifact for things like session
> management (we can define a new artifact for that purpose that fits
> better). This effectively means that we don’t need to redefine the ID Token
> because we don’t need the equivalent of the ID token in the same way. For
> the cases that we do need to define user claims, we should be defining them
> as a JSON object model. And I also believe that this JSON data model should
> not be intertwined with or constrained by the JWT claims registry. The OIDC
> claims registry can serve as influence and input to our user claims set if
> we choose, but I don’t think we should be intertwined with that either.
>
> Second, in spite of the success of OIDC, there are several formats out
> there for user claims beyond JWT and JOSE. Verifiable Credentials (VC,
> https://www.w3.org/TR/vc-data-model/) is one that has several different
> formats, and we are also seeing systems built up around COSE and CBOR (like
> IPLD, https://ipld.io/). Or you could even use a SAML document. I don’t
> think TxAuth should pick just one of these. Instead, I want TxAuth to
> define places to put these formats in requests and responses. In my draft
> there’s a spot for an OIDC style ID Token or a VC document, if you have
> one. Within each of these, by all means, let’s lock them down and say that
> the “oidc_id_token” field is a JWT in compact format that MUST be signed,
> etc. And I think it makes little sense to invent our own custom format to
> do exactly that kind of thing.
>
> Third, I agree that we shouldn’t re-invent an existing crypto format, and
> I’ll go further that we shouldn’t be inventing crypto at all. This doesn’t
> mean we have to pick one and only one, because this is one of the spaces
> that we can (and I argue should) have some agility. We can define the
> protocol in terms of JSON and then have a suite of cryptographic carriers
> that protect that JSON, including JOSE, HTTP Message Signatures, and Mutual
> TLS. There are a bunch of others out there as well, like the DPoP key
> presentation coming out of OAuth 2 right now, that should be switchable as
> options here because they’re going to apply to different use cases and
> deployments. Plus, that JSON could be translated to CBOR (without data or
> structure loss) and protected by COSE — even if we don’t define that
> ourselves, the fact that we’re building our structure on raw JSON means
> that it can be translated more easily later.
>
> Fourth, I am very sensitive to calling out preferred crypto solutions
> because I believe that lends to us using that as an excuse to use that
> particular hammer to solve all the problems. There have been proposals to
> make the entire protocol JWTs in all directions, for instance, that I think
> are really problematic because of the limits that it places on expression
> of items outside of the payload itself. This is not what Mike is suggesting
> below, but it’s a potential fallout from what he does propose.
>
>
>
> In conclusion, JOSE and JWT are fantastic and they solve a lot of problems
> in an elegant way. But I think we need to question whether we need their
> solutions at all, and where we do, if we want to enable other solutions as
> well. In my view, we don’t need JOSE/JWT because we avoid the problems that
> they solve, and the places that we do want to use them I strongly believe
> there are already other alternatives that we want to have as options.
>
> So I want to have JOSE, but it needs to be in the right places and I do
> not want it to be a dependency on all implementations. I think that we can
> do that without saying JWT is a preferred format. I think it’s more
> important that the charter incorporate specific text of what’s out of
> scope, including defining a cryptographic protection mechanism.
>
> One of the hardest things for a standard to do is determine where the
> flexibility should be. My stance is that we should have a structural format
> based on JSON but that the contents of that JSON are extensible but that
> each portion and extension are very strict about what’s there. Another key
> flexible point is that the content of the JSON-based payloads can be
> protected in a variety of ways. Choice can be debilitating, but it can also
> be freeing. Pinning everything to JOSE would do us a disservice.
>
>  — Justin
>
> I strongly object to calling out JWTs as the preferred solution for signed
> and encrypted claims within this working group.
>
>  — Justin
>
> Thanks for writing these detailed questions, Kim.  I believe that they
> point out a number of places where even experts in the field, such as
> yourself, currently have trouble understanding parts of what the charter is
> proposing that we do – partially because terminology is used that isn’t
> commonly understood.  I hope that the draft charter will be revised to make
> the intent and the goals more accessible and less ambiguous.
>
> Responding to the discussion on whether existing JWT identity claims will
> do the job or not, fortunately, even if they don’t, there’s a mechanism to
> add ones that do: the IANA JSON Web Token Claims registry at
> https://www.iana.org/assignments/jwt/jwt.xhtml#claims.  For instance, an
> “email_addresses” claim that is array-valued could be defined and
> registered if there’s a need to represent multiple e-mail addresses, per
> Annabelle’s example.  The further good news is that if the working group
> defines new claims that are registered, they can be reused by others also
> using JWTs – just like this working group can reuse claims defined by
> others.
>
> Also on the subject of JWTs, I would suggest that the charter be updated
> to explicitly call out that JWTs will be the working group’s preferred
> representation signed and/or encrypted claims.
>
> Finally, I also think that the charter would benefit from explicitly
> listing things that are out of scope (which is often done in charters).
>
> *From:* Txauth <[email-masked]> *On Behalf Of *Justin Richer
> *Sent:* Wednesday, January 29, 2020 12:46 AM
> *To:* Torsten Lodderstedt <[email-masked]>
> *Cc:* Kim <[email-masked]>; Dick Hardt <[email-masked]>;
> [email-masked]; Richard Backman, Annabelle <
> richanna=[email-masked]>
> *Subject:* [EXTERNAL] Re: [Txauth] Questions on the TxAuth charter
>
> I didn’t mean “patch” to sound disparaging, sorry if it came across as
> such. What I mean by “patching” here is that it is adding functionality to
> an existing set of claims and schema. If you are using that schema as a
> base, it makes sense as a viable solution in that space. I, however, am
> bringing up the question of whether we are using that schema as our base at
> all.
>
> I’ll note that 8112 doesn’t define a schema or syntax, both of which are
> required. But if we were starting OIDC today with EKYC’s requirements, I’m
> not convinced we’d end up with the same structure.
>
> As with everything, it’s a very important input into what we’re trying to
> solve, especially influencing what’s extensible and how.
>
>  — Justin
>
>
> I think the ekyc work is great for what it is, but again we have an
> opportunity to take a step beyond it. In my view, we’d be better off
> defining a means of specifying field metadata a la NIST IR 8112 as part of
> the schema instead of patching the existing OIDC fields.
> https://pages.nist.gov/NISTIR-8112/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpages.nist.gov%2FNISTIR-8112%2F&data=02%7C01%7CMichael.Jones%40microsoft.com%7C9fae503669f443a0968308d7a497c45f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158844049338344&sdata=rOrKaO7MvDDKLyfB2QivbVTcj5EmRSJ1nRXXs30jEz0%3D&reserved=0>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fwg%2Fekyc-ida%2F&data=02%7C01%7CMichael.Jones%40microsoft.com%7C9fae503669f443a0968308d7a497c45f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158844049338344&sdata=pg8upwyN%2BXKeaFZaKEvR%2BTEPsKgjeJtdHwPM1fe%2Fxnc%3D&reserved=0>
>
>
> --
> Txauth mailing list
> [email-masked]

---

From: Dick Hardt <[email-masked]>
Date: Wed, 29 Jan 2020 13:14:43 -0800

Forking the discussion to focus on signed claims

<snip>

> we choose, but I don’t think we should be intertwined with that either.

I disagree. I think it is likely that we will see an increase in signed
claims and messages.

In my opinion, the providence of a claim or message is far more important
than protection during transit.

*Client / AS non-repudiation*: when sensitive operations are performed
relying on the contents of a claim, the Client will want repudiation that
the AS or claims issuer made a claim.

*Separation of duties in complex systems*: In large organizations, a major
security threat is a malicious insider. Once an organization reaches a
certain size, you assume there are people employed at the company that do
not have the firms best interests in mind. One mitigation of this threat is
done by separating what different teams can do with customer / sensitive
data, requiring collusion to access or modify the data. Signed messages and
claims simplify different components being able to independently verify a
message or claim. Similarly, a component issuing a claim, has assurance
that other components in the same system are not modifying it. Large
organizations wrap external systems that do not support this with their own
security mechanism -- but not all organizations are this sophisticated, and
as they grow, retrofitting is difficult. Enabling end to end providence is
a best practice in my opinion.

*User Consent Audit*: as privacy becomes a larger public topic, it is easy
to imagine organizations wanting to prove that they obtained user
information with consent. Rather than gathering user information directly
from the user, a Client can acquire claims from the User's claims provider
that asserts the user provided consent to the Client. The Client can then
technically establish that all user data was gathered with consent, and the
context of the consent.

While the message containing the claims may be signed, having independent
claims separately signed simplifies the least privilege tenet, where a
component only has access to the user information it needs.

/Dick

---

From: Dick Hardt <[email-masked]>
Date: Wed, 29 Jan 2020 14:15:34 -0800

I forgot to include the reference to Annabelle calling this out earlier

https://mailarchive.ietf.org/arch/msg/txauth/0hR49OnE3oqNPuCIQ43fN1o886w

On Wed, Jan 29, 2020 at 1:14 PM Dick Hardt <[email-masked]> wrote:

> *Separation of duties in complex systems*: In large organizations, a
> major security threat is a malicious insider. Once an organization reaches
> a certain size, you assume there are people employed at the company that do
> *User Consent Audit*: as privacy becomes a larger public topic, it is
> easy to imagine organizations wanting to prove that they obtained user

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 30 Jan 2020 00:00:59 +0000

+1 to Dick’s counterpoints. The Security Considerations in draft-ietf-secevent-http-push<https://tools.ietf.org/html/draft-ietf-secevent-http-push-07#section-5.4> talk about validation of persisted SETs as one reason a deployment may wish to transmit signed SETs even over a TLS-protected channel. The same idea applies to identity claims or just about anything else, really.

–

From: Dick Hardt <[email-masked]>
Date: Wednesday, January 29, 2020 at 2:16 PM
To: Justin Richer <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Kim <[email-masked]>, Torsten Lodderstedt <[email-masked]>, "Richard Backman, Annabelle" <[email-masked]>, Mike Jones <[email-masked]>
Subject: [UNVERIFIED SENDER] Re: The need for signed claims - providence

On Wed, Jan 29, 2020 at 1:14 PM Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
Forking the discussion to focus on signed claims

On Wed, Jan 29, 2020 at 3:37 AM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
<snip>
First, I don’t believe there are going to be many, if any, cases where we need user claims to be signed and encrypted separately from the core transaction messages. Even in OIDC, the ID Token is allowed to be unsigned when it is retrieved from the token endpoint directly using the code flow. The equivalent of this is the only place that TxAuth would be sending back user claims directly. We no longer have a need to protect things as they travel through the front channel on a redirect, and we no longer have a need to use the user’s claims as an artifact for things like session management (we can define a new artifact for that purpose that fits better). This effectively means that we don’t need to redefine the ID Token because we don’t need the equivalent of the ID token in the same way.. For the cases that we do need to define user claims, we should be defining them as a JSON object model. And I also believe that this JSON data model should not be intertwined with or constrained by the JWT claims registry. The OIDC claims registry can serve as influence and input to our user claims set if we choose, but I don’t think we should be intertwined with that either.

I disagree. I think it is likely that we will see an increase in signed claims and messages.

In my opinion, the providence of a claim or message is far more important than protection during transit.

Client / AS non-repudiation: when sensitive operations are performed relying on the contents of a claim, the Client will want repudiation that the AS or claims issuer made a claim.

Separation of duties in complex systems: In large organizations, a major security threat is a malicious insider. Once an organization reaches a certain size, you assume there are people employed at the company that do not have the firms best interests in mind. One mitigation of this threat is done by separating what different teams can do with customer / sensitive data, requiring collusion to access or modify the data. Signed messages and claims simplify different components being able to independently verify a message or claim. Similarly, a component issuing a claim, has assurance that other components in the same system are not modifying it. Large organizations wrap external systems that do not support this with their own security mechanism -- but not all organizations are this sophisticated, and as they grow, retrofitting is difficult. Enabling end to end providence is a best practice in my opinion.

User Consent Audit: as privacy becomes a larger public topic, it is easy to imagine organizations wanting to prove that they obtained user information with consent. Rather than gathering user information directly from the user, a Client can acquire claims from the User's claims provider that asserts the user provided consent to the Client. The Client can then technically establish that all user data was gathered with consent, and the context of the consent.

While the message containing the claims may be signed, having independent claims separately signed simplifies the least privilege tenet, where a component only has access to the user information it needs..

/Dick

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 30 Jan 2020 00:55:32 +0000

I’m going to approach this from a different angle… As I’ve said before, I think a charter should be closer to a problem statement than a design document. It should focus on what the group is trying to do, not how they’re going to do it. The reason for the working group is, after all, to figure out the “how” part. To that end, a charter should not prescribe specific technologies or design choices. Doing so unnecessarily constrains the working group and provides zero benefit. If everyone agrees that technology X is the right choice when writing the charter, they’ll agree that it is the right choice when writing working group drafts…unless something has changed – new information has come out, new use cases, new technologies, additional stakeholders have gotten involved, etc. – in which case it may be very important that the working group have the freedom to explore other options.

Sometimes the problem to be solved needs to be scoped down along technology lines (e.g., HTTP APIs versus APIs on any protocol imaginable) in order to make it tractable. I am not opposed to those constraints when they are needed, though often they can be handled with a “we will initially focus on…” rather than a hard “we will only support…” as demonstrated by the TxAuth charter’s approach to HTTP vs COAP. In any case, I do not see JWT or OIDC claims as necessary constraints to scope the problem down. They may well be the right choices for what they are being suggested for here, but having that debate now is unnecessary and potentially harmful (see above), and will needlessly delay the formation of the working group and development of the protocol.

–

From: Txauth <[email-masked]> on behalf of Justin Richer <[email-masked]>
Date: Wednesday, January 29, 2020 at 3:38 AM
To: "[email-masked]" <[email-masked]>
Cc: Kim <[email-masked]>, Mike Jones <[email-masked]>, Torsten Lodderstedt <[email-masked]>, Dick Hardt <[email-masked]>, "Richard Backman, Annabelle" <richanna=[email-masked]>
Subject: Re: [Txauth] [EXTERNAL] Re: Questions on the TxAuth charter

 — Justin

On Jan 29, 2020, at 10:05 AM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

 — Justin

On Jan 29, 2020, at 9:50 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                       -- Mike

From: Txauth <[email-masked]<mailto:[email-masked]>> On Behalf Of Justin Richer
Sent: Wednesday, January 29, 2020 12:46 AM
To: Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>>
Cc: Kim <[email-masked]<mailto:[email-masked]>>; Dick Hardt <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Richard Backman, Annabelle <richanna=[email-masked]<mailto:richanna=[email-masked]>>
Subject: [EXTERNAL] Re: [Txauth] Questions on the TxAuth charter

 — Justin

 — Justin

--
Txauth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

---

From: Justin Richer <[email-masked]>
Date: Thu, 30 Jan 2020 07:19:04 +0100

I think the use cases for SET are very different from an authentication assertion, which is consumed then discarded. Aaron Parecki has written a good blog post that touches on this:

https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz

If we need a persistent record then we can also send that — maybe it’s even a SET instead of an ID Token? I’m still fine with enabling signed JWTs to carry information, but what I was against was stating any assumption that they would always be signed or encrypted, and that JWT would be the assumed carrier for that.

 — Justin

> On Jan 30, 2020, at 1:00 AM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> +1 to Dick’s counterpoints. The Security Considerations in draft-ietf-secevent-http-push <https://tools.ietf.org/html/draft-ietf-secevent-http-push-07#section-5.4> talk about validation of persisted SETs as one reason a deployment may wish to transmit signed SETs even over a TLS-protected channel. The same idea applies to identity claims or just about anything else, really.
>  
> – 
> https://mailarchive.ietf.org/arch/msg/txauth/0hR49OnE3oqNPuCIQ43fN1o886w <https://mailarchive.ietf.org/arch/msg/txauth/0hR49OnE3oqNPuCIQ43fN1o886w>
>  
>  
> On Wed, Jan 29, 2020 at 1:14 PM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>> On Wed, Jan 29, 2020 at 3:37 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> <snip>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 29 Jan 2020 22:58:02 -0800

Justin: would you respond to my critique of your statement? I was not
talking about SETs.

Tl;dr: multiple services in a pipeline in a complex app may need to
independently verify a claim.
ᐧ

On Wed, Jan 29, 2020 at 10:19 PM Justin Richer <[email-masked]> wrote:

> I think the use cases for SET are very different from an authentication
> assertion, which is consumed then discarded. Aaron Parecki has written a
> good blog post that touches on this:
>
> If we need a persistent record then we can also send that — maybe it’s
> even a SET instead of an ID Token? I’m still fine with enabling signed JWTs
> to carry information, but what I was against was stating any assumption
> that they would always be signed or encrypted, and that JWT would be the
> assumed carrier for that.
>
>  — Justin
>
> +1 to Dick’s counterpoints. The Security Considerations in
> draft-ietf-secevent-http-push
> <https://tools.ietf.org/html/draft-ietf-secevent-http-push-07#section-5.4>
>  talk about validation of persisted SETs as one reason a deployment may
> wish to transmit signed SETs even over a TLS-protected channel. The same
> idea applies to identity claims or just about anything else, really.
>
> –
> *Date: *Wednesday, January 29, 2020 at 2:16 PM
> *To: *Justin Richer <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Kim <[email-masked]>,
> Torsten Lodderstedt <[email-masked]>, "Richard Backman,
> Annabelle" <[email-masked]>, Mike Jones <[email-masked]>
> *Subject: *[UNVERIFIED SENDER] Re: The need for signed claims - providence
>
> because we don’t need the equivalent of the ID token in the same way.. For
> component only has access to the user information it needs..
>
> /Dick
>
>
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 30 Jan 2020 08:55:08 +0100

I did: My response to your point was that we should enable this kind of thing but not assume that user claims are going to be — or need to be — in a signed payload. I think that what you’re describing is a specific architecture decision which is not that common. It shouldn’t be disallowed but I don’t think other deployments should pay that cost. 

Even in OIDC today, you’re allowed to ignore the signature on the signed ID Token if it gets delivered on the back channel. In the normal case, a JWT provides just an extra layer of wrapping without much value. Please see Aaron’s post for a better writeup of that.

So in the end, I think that plain JSON should be enabled for user claims (which XAuth also has, I’ll note) along with any type of packaged assertion like an ID Token (which I’ll note that XYZ also has).

 — Justin

> On Jan 30, 2020, at 7:58 AM, Dick Hardt <[email-masked]> wrote:
> 
> Justin: would you respond to my critique of your statement? I was not talking about SETs.
> 
> Tl;dr: multiple services in a pipeline in a complex app may need to independently verify a claim. 
> ᐧ
> 
> On Wed, Jan 29, 2020 at 10:19 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz <https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz>
> 
>> On Jan 30, 2020, at 1:00 AM, Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> From: Dick Hardt <[email-masked] <mailto:[email-masked]>>
>> To: Justin Richer <[email-masked] <mailto:[email-masked]>>
>> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Kim <[email-masked] <mailto:[email-masked]>>, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>>, "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>, Mike Jones <[email-masked] <mailto:[email-masked]>>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 30 Jan 2020 11:22:24 -0800

My point was disagreeing with your assertion:

transaction messages.

Sharing the entire transaction with services that only need specific claims
would go against the minimal disclosure tenet.

On Wed, Jan 29, 2020 at 11:55 PM Justin Richer <[email-masked]> wrote:

> I did: My response to your point was that we should enable this kind of
> thing but not assume that user claims are going to be — or need to be — in
> a signed payload. I think that what you’re describing is a specific
> architecture decision which is not that common. It shouldn’t be disallowed
> but I don’t think other deployments should pay that cost.
>
> Even in OIDC today, you’re allowed to ignore the signature on the signed
> ID Token if it gets delivered on the back channel. In the normal case, a
> JWT provides just an extra layer of wrapping without much value. Please see
> Aaron’s post for a better writeup of that.
>
> So in the end, I think that plain JSON should be enabled for user claims
> (which XAuth also has, I’ll note) along with any type of packaged assertion
> like an ID Token (which I’ll note that XYZ also has).
>
>  — Justin
>
>> Annabelle" <[email-masked]>, Mike Jones <[email-masked]
>> >

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 30 Jan 2020 20:09:36 +0000

I am not arguing that claims always need to be independently signed, and I don’t believe Dick is either. My concern arose from this bit of your follow up response to Mike:

Even in OIDC, the ID Token is allowed to be unsigned when it is retrieved from the token endpoint directly using the code flow. The equivalent of this is the only place that TxAuth would be sending back user claims directly.

This sounded to me like you were saying that the only reason for signing or encrypting the ID Token is to secure it as it passes through the front channel. That is not the case, as Dick explained.

Fortunately, I don’t think any of this matters as far as the charter is concerned. It is sufficient for the charter to say that identity is in scope. The specific mechanism(s) can and should be determined by the working group, in the context of a draft specification. Including a particular problem within the scope of the working group does not mean that the working group has to invent a brand new way to solve that problem. It just means that we can invent something new, if we determine it is worthwhile to do so.

–

From: Dick Hardt <[email-masked]>
Date: Thursday, January 30, 2020 at 11:23 AM
To: Justin Richer <[email-masked]>
Cc: "Richard Backman, Annabelle" <[email-masked]>, "[email-masked]" <[email-masked]>, Kim <[email-masked]>, Torsten Lodderstedt <[email-masked]>, Mike Jones <[email-masked]>
Subject: Re: [UNVERIFIED SENDER] Re: The need for signed claims - providence

First, I don’t believe there are going to be many, if any, cases where we need user claims to be signed and encrypted separately from the core transaction messages.

Sharing the entire transaction with services that only need specific claims would go against the minimal disclosure tenet.

On Wed, Jan 29, 2020 at 11:55 PM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
I did: My response to your point was that we should enable this kind of thing but not assume that user claims are going to be — or need to be — in a signed payload. I think that what you’re describing is a specific architecture decision which is not that common. It shouldn’t be disallowed but I don’t think other deployments should pay that cost.

 — Justin

On Jan 30, 2020, at 7:58 AM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:

Tl;dr: multiple services in a pipeline in a complex app may need to independently verify a claim.
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=03e26191-cfe7-43dc-900c-1500ddf37cf0]ᐧ

On Wed, Jan 29, 2020 at 10:19 PM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
I think the use cases for SET are very different from an authentication assertion, which is consumed then discarded. Aaron Parecki has written a good blog post that touches on this:

 — Justin

On Jan 30, 2020, at 1:00 AM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

–

From: Dick Hardt <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, January 29, 2020 at 2:16 PM
To: Justin Richer <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Kim <[email-masked]<mailto:[email-masked]>>, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>>, "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>, Mike Jones <[email-masked]<mailto:[email-masked]>>
Subject: [UNVERIFIED SENDER] Re: The need for signed claims - providence

/Dick

---

From: Justin Richer <[email-masked]>
Date: Fri, 31 Jan 2020 07:22:48 +0100

I agree with this direction and it’s in line with what my response was trying to say. The implications of Mike’s suggested statement was that we would predetermine a preferred method of signing things as part of the charter. I’m against that. I’m not against us coming up with a preferred way to sign things, and not against reusing an existing technology to do so. But none of that should be specified as such in the charter as constraining the solution space at this level, in my opinion.

In other words, I don’t think we need to or should alter the charter to address this point.

 — Justin

> On Jan 30, 2020, at 9:09 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> Fortunately, I don’t think any of this matters as far as the charter is concerned. It is sufficient for the charter to say that identity is in scope. The specific mechanism(s) can and should be determined by the working group, in the context of a draft specification. Including a particular problem within the scope of the working group does not mean that the working group has to invent a brand new way to solve that problem. It just means that we caninvent something new, if we determine it is worthwhile to do so.
>  
> – 
> On Wed, Jan 29, 2020 at 11:55 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>>> On Jan 30, 2020, at 7:58 AM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>>>