subject:"Re\: \[OAUTH\-WG\] draft\-bertocci\-oauth\-access\-token\-jwt\-00"

Let me try a different angle. An AS might generate sub claims and client_id
identifiers using a different format/template. That means that there might
be a client with client_id X that gets assigned a sub value Y, despite the
client being the same, hence the check “sub==client_id” would fail.
The logic producing this might be hard for an AS to change as there has
never been any requirement on client_id or sub formats hence everyone was
free until now to use whatever logic they chose, including name spacing one
but not the other and any other variation, and changes might have ripple
effects downstream on systems that have nothing to do w this spec (eg
sharing of where clients are stored might depend on the internal structure
of the client_id). So in other words, an AS might have to touch pretty
fundamental stuff in its logic and potentially impact scenarios that have
no direct bearing with the JWT AT profile just for making that condition
true. On the other plate of the scale, there’s adding a new claim- which I
can literally already do in various commercial ASes via extensibility
points, without changing their code.


On Mon, May 6, 2019 at 15:11 Hans Zandbelt 
wrote:

> I'm suggesting that whichever "sub" and "client_id" the RS is receiving
> and however it was generated, it must mean something to it in alignment
> with the JWT/OAuth2/OIDC specs, otherwise it wouldn't be there at all;
> moreover, if the "sub" has the same value as "client_id" it must be a
> client talking to the RS on behalf of its own and the claims are associated
> with the client; if the "sub" has a different value than the "client_id" it
> must be a scenario where the client presents a token delegated by a
> Resource Owner and the claims are about the Resource Owner. Problem solved?
>
> Hans.
>
> On Mon, May 6, 2019 at 11:06 PM Vittorio Bertocci 
> wrote:
>
>> I am not following. We want this to be adopted, right? :) if we provide
>> guidance that is sound but hard to implement we are going to fail.
>> Considerations on whether the guidance requires a big effort to be applied
>> are very much in scope for me.
>>
>> On Mon, May 6, 2019 at 14:54 Hans Zandbelt 
>> wrote:
>>
>>> the scope and way of generating sub/client_id is orthogonal to the
>>> semantics IMHO but if I'm the only one who thinks so, I'll rest my case
>>>
>>> Hans.
>>>
>>> On Mon, May 6, 2019 at 10:49 PM Vittorio Bertocci 
>>> wrote:
>>>
 See below, Hans- the sub doesn’t have to be global, it could be
 something generated just for this particular RS. Or the AS might have its
 own recipe for generating sub values that different from the recipe used to
 generate client_ids. It would be much easier for an AS to emit a claim
 making this explicit statement than to change sub and client_id assignment
 logic.

 On Mon, May 6, 2019 at 13:49 Hans Zandbelt 
 wrote:

> I may be missing something but I'd argue that by requiring and
> comparing both "sub" and "client_id" we achieve the same semantics without
> a new/additional claim (barring name spacing)
>
> Hans.
>
> On Mon, May 6, 2019 at 8:58 PM Karl McGuinness  40okta@dmarc.ietf.org> wrote:
>
>> Makes sense that we don’t want to further couple AS and RS with grant
>> types.  I’m OK if we want a dedicated claim to establish whether the 
>> token
>> is resource owner delegated  vs client acting as itself.
>>
>> Subject Type is already a concept in RISC.  Just making folks are
>> aware of prior art.
>>
>> https://openid.net/specs/oauth-event-types-1_0-01.html#rfc.section.2..2
>> https://openid.net/specs/openid-risc-profile-1_0.html#rfc.section.2.1
>>
>> -Karl
>>
>> On May 6, 2019, at 12:42 PM, Vittorio Bertocci <
>> Vittorio=40auth0@dmarc.ietf.org> wrote:
>>
>> *This message originated outside your organization.*
>> --
>> Fair enough! What others think about it?
>> Exploring the approach: would we want a bool claim or an enumeration,
>> e.g. sub_type = [ resource_owner | client ] ?
>>
>>
>> On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov <
>> vladi...@connect2id.com> wrote:
>>
>>> Hi Vittorio,
>>>
>>> On 06/05/2019 22:22, Vittorio Bertocci wrote:
>>> > It is true that the grant_type is a client side consideration. I
>>> did think
>>> > about the "client_id==sub" heuristic, but that's not always
>>> applicable:
>>> > many systems have their own rules for generating sub, and in case
>>> they want
>>> > to prevent tracking across RSes the sub might be generated ad-hoc
>>> for that
>>> > particular RS.
>>> > Would you prefer to have a dedicated claim that distinguish
>>> between user
>>> > and app tokens rather than reusing grant_type?
>>>
>>> A dedicated claim to flag client_id effectively == sub would be
>>> preferable, and much easier for RS

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

2019-05-06 Thread Hans Zandbelt

I'm suggesting that whichever "sub" and "client_id" the RS is receiving and
however it was generated, it must mean something to it in alignment with
the JWT/OAuth2/OIDC specs, otherwise it wouldn't be there at all; moreover,
if the "sub" has the same value as "client_id" it must be a client talking
to the RS on behalf of its own and the claims are associated with the
client; if the "sub" has a different value than the "client_id" it must be
a scenario where the client presents a token delegated by a Resource Owner
and the claims are about the Resource Owner. Problem solved?

Hans.

On Mon, May 6, 2019 at 11:06 PM Vittorio Bertocci 
wrote:

> I am not following. We want this to be adopted, right? :) if we provide
> guidance that is sound but hard to implement we are going to fail.
> Considerations on whether the guidance requires a big effort to be applied
> are very much in scope for me.
>
> On Mon, May 6, 2019 at 14:54 Hans Zandbelt 
> wrote:
>
>> the scope and way of generating sub/client_id is orthogonal to the
>> semantics IMHO but if I'm the only one who thinks so, I'll rest my case
>>
>> Hans.
>>
>> On Mon, May 6, 2019 at 10:49 PM Vittorio Bertocci 
>> wrote:
>>
>>> See below, Hans- the sub doesn’t have to be global, it could be
>>> something generated just for this particular RS. Or the AS might have its
>>> own recipe for generating sub values that different from the recipe used to
>>> generate client_ids. It would be much easier for an AS to emit a claim
>>> making this explicit statement than to change sub and client_id assignment
>>> logic.
>>>
>>> On Mon, May 6, 2019 at 13:49 Hans Zandbelt 
>>> wrote:
>>>
 I may be missing something but I'd argue that by requiring and
 comparing both "sub" and "client_id" we achieve the same semantics without
 a new/additional claim (barring name spacing)

 Hans.

 On Mon, May 6, 2019 at 8:58 PM Karl McGuinness >>> 40okta@dmarc.ietf.org> wrote:

> Makes sense that we don’t want to further couple AS and RS with grant
> types.  I’m OK if we want a dedicated claim to establish whether the token
> is resource owner delegated  vs client acting as itself.
>
> Subject Type is already a concept in RISC.  Just making folks are
> aware of prior art.
>
> https://openid.net/specs/oauth-event-types-1_0-01.html#rfc.section.2.2
> https://openid.net/specs/openid-risc-profile-1_0.html#rfc.section.2.1
>
> -Karl
>
> On May 6, 2019, at 12:42 PM, Vittorio Bertocci <
> Vittorio=40auth0@dmarc.ietf.org> wrote:
>
> *This message originated outside your organization.*
> --
> Fair enough! What others think about it?
> Exploring the approach: would we want a bool claim or an enumeration,
> e.g. sub_type = [ resource_owner | client ] ?
>
>
> On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov <
> vladi...@connect2id.com> wrote:
>
>> Hi Vittorio,
>>
>> On 06/05/2019 22:22, Vittorio Bertocci wrote:
>> > It is true that the grant_type is a client side consideration. I
>> did think
>> > about the "client_id==sub" heuristic, but that's not always
>> applicable:
>> > many systems have their own rules for generating sub, and in case
>> they want
>> > to prevent tracking across RSes the sub might be generated ad-hoc
>> for that
>> > particular RS.
>> > Would you prefer to have a dedicated claim that distinguish between
>> user
>> > and app tokens rather than reusing grant_type?
>>
>> A dedicated claim to flag client_id effectively == sub would be
>> preferable, and much easier for RS developers to process.
>>
>> The AS is the authority and has all the knowledge to set / indicate
>> this.
>>
>> I want to keep RS developers away from having to deal with grant types
>> and having to make decisions whether client_id effectively == sub.
>>
>> Vladimir
>>
>>
>> > On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov <
>> vladi...@connect2id.com>
>> > wrote:
>> >
>> >> On 06/05/2019 20:32, Vittorio Bertocci wrote:
>> >>> To that end, *Karl MCGuinness suggested that we include
>> >>> grant_type as a return claim, which the RS could use to the same
>> >> effect*. I
>> >>> find the proposal very clever, and the people at IIW thought so
>> as well.
>> >>> What you think?
>> >> The grant type is not something that the RS is really concerned
>> with, or
>> >> should be. Introducing this parameter in the access token will
>> create an
>> >> additional logical dependency, plus complexity - in the system of
>> >> client, AS and RS as a whole, as well as for RS developers. The
>> grant
>> >> type, as a concept, is a matter between the client and AS, and IMO
>> >> should stay that way.
>> >>
>> >> Clear language in the spec should suffice. For instance: "If

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

I am not following. We want this to be adopted, right? :) if we provide
guidance that is sound but hard to implement we are going to fail.
Considerations on whether the guidance requires a big effort to be applied
are very much in scope for me.

On Mon, May 6, 2019 at 14:54 Hans Zandbelt 
wrote:

> the scope and way of generating sub/client_id is orthogonal to the
> semantics IMHO but if I'm the only one who thinks so, I'll rest my case
>
> Hans.
>
> On Mon, May 6, 2019 at 10:49 PM Vittorio Bertocci 
> wrote:
>
>> See below, Hans- the sub doesn’t have to be global, it could be something
>> generated just for this particular RS. Or the AS might have its own recipe
>> for generating sub values that different from the recipe used to generate
>> client_ids. It would be much easier for an AS to emit a claim making this
>> explicit statement than to change sub and client_id assignment logic.
>>
>> On Mon, May 6, 2019 at 13:49 Hans Zandbelt 
>> wrote:
>>
>>> I may be missing something but I'd argue that by requiring and comparing
>>> both "sub" and "client_id" we achieve the same semantics without a
>>> new/additional claim (barring name spacing)
>>>
>>> Hans.
>>>
>>> On Mon, May 6, 2019 at 8:58 PM Karl McGuinness >> 40okta@dmarc.ietf.org> wrote:
>>>
 Makes sense that we don’t want to further couple AS and RS with grant
 types.  I’m OK if we want a dedicated claim to establish whether the token
 is resource owner delegated  vs client acting as itself.

 Subject Type is already a concept in RISC.  Just making folks are aware
 of prior art.

 https://openid.net/specs/oauth-event-types-1_0-01.html#rfc.section.2.2
 https://openid.net/specs/openid-risc-profile-1_0.html#rfc.section.2.1

 -Karl

 On May 6, 2019, at 12:42 PM, Vittorio Bertocci <
 Vittorio=40auth0@dmarc.ietf.org> wrote:

 *This message originated outside your organization.*
 --
 Fair enough! What others think about it?
 Exploring the approach: would we want a bool claim or an enumeration,
 e.g. sub_type = [ resource_owner | client ] ?


 On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov <
 vladi...@connect2id.com> wrote:

> Hi Vittorio,
>
> On 06/05/2019 22:22, Vittorio Bertocci wrote:
> > It is true that the grant_type is a client side consideration. I did
> think
> > about the "client_id==sub" heuristic, but that's not always
> applicable:
> > many systems have their own rules for generating sub, and in case
> they want
> > to prevent tracking across RSes the sub might be generated ad-hoc
> for that
> > particular RS.
> > Would you prefer to have a dedicated claim that distinguish between
> user
> > and app tokens rather than reusing grant_type?
>
> A dedicated claim to flag client_id effectively == sub would be
> preferable, and much easier for RS developers to process.
>
> The AS is the authority and has all the knowledge to set / indicate
> this.
>
> I want to keep RS developers away from having to deal with grant types
> and having to make decisions whether client_id effectively == sub..
>
> Vladimir
>
>
> > On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov <
> vladi...@connect2id.com>
> > wrote:
> >
> >> On 06/05/2019 20:32, Vittorio Bertocci wrote:
> >>> To that end, *Karl MCGuinness suggested that we include
> >>> grant_type as a return claim, which the RS could use to the same
> >> effect*. I
> >>> find the proposal very clever, and the people at IIW thought so as
> well.
> >>> What you think?
> >> The grant type is not something that the RS is really concerned
> with, or
> >> should be. Introducing this parameter in the access token will
> create an
> >> additional logical dependency, plus complexity - in the system of
> >> client, AS and RS as a whole, as well as for RS developers. The
> grant
> >> type, as a concept, is a matter between the client and AS, and IMO
> >> should stay that way.
> >>
> >> Clear language in the spec should suffice. For instance: "If the sub
> >> value matches the client_id value, then the subject is the client
> >> application".
> >>
> >> Vladimir
> >>
> >> --
> >> Vladimir Dzhuvinov
> >>
> >>
> >> ___
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> --
> Vladimir Dzhuvinov
>
>
> ___
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth


 ___
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>

>>>
>>> --
>>>

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

2019-05-06 Thread Hans Zandbelt

the scope and way of generating sub/client_id is orthogonal to the
semantics IMHO but if I'm the only one who thinks so, I'll rest my case

Hans.

On Mon, May 6, 2019 at 10:49 PM Vittorio Bertocci 
wrote:

> See below, Hans- the sub doesn’t have to be global, it could be something
> generated just for this particular RS. Or the AS might have its own recipe
> for generating sub values that different from the recipe used to generate
> client_ids. It would be much easier for an AS to emit a claim making this
> explicit statement than to change sub and client_id assignment logic.
>
> On Mon, May 6, 2019 at 13:49 Hans Zandbelt 
> wrote:
>
>> I may be missing something but I'd argue that by requiring and comparing
>> both "sub" and "client_id" we achieve the same semantics without a
>> new/additional claim (barring name spacing)
>>
>> Hans.
>>
>> On Mon, May 6, 2019 at 8:58 PM Karl McGuinness > 40okta@dmarc.ietf.org> wrote:
>>
>>> Makes sense that we don’t want to further couple AS and RS with grant
>>> types.  I’m OK if we want a dedicated claim to establish whether the token
>>> is resource owner delegated  vs client acting as itself.
>>>
>>> Subject Type is already a concept in RISC.  Just making folks are aware
>>> of prior art.
>>>
>>> https://openid.net/specs/oauth-event-types-1_0-01.html#rfc.section.2.2
>>> https://openid.net/specs/openid-risc-profile-1_0.html#rfc.section.2.1
>>>
>>> -Karl
>>>
>>> On May 6, 2019, at 12:42 PM, Vittorio Bertocci <
>>> Vittorio=40auth0@dmarc.ietf.org> wrote:
>>>
>>> *This message originated outside your organization.*
>>> --
>>> Fair enough! What others think about it?
>>> Exploring the approach: would we want a bool claim or an enumeration,
>>> e.g. sub_type = [ resource_owner | client ] ?
>>>
>>>
>>> On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov <
>>> vladi...@connect2id.com> wrote:
>>>
 Hi Vittorio,

 On 06/05/2019 22:22, Vittorio Bertocci wrote:
 > It is true that the grant_type is a client side consideration. I did
 think
 > about the "client_id==sub" heuristic, but that's not always
 applicable:
 > many systems have their own rules for generating sub, and in case
 they want
 > to prevent tracking across RSes the sub might be generated ad-hoc for
 that
 > particular RS.
 > Would you prefer to have a dedicated claim that distinguish between
 user
 > and app tokens rather than reusing grant_type?

 A dedicated claim to flag client_id effectively == sub would be
 preferable, and much easier for RS developers to process.

 The AS is the authority and has all the knowledge to set / indicate
 this.

 I want to keep RS developers away from having to deal with grant types
 and having to make decisions whether client_id effectively == sub.

 Vladimir


 > On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov <
 vladi...@connect2id.com>
 > wrote:
 >
 >> On 06/05/2019 20:32, Vittorio Bertocci wrote:
 >>> To that end, *Karl MCGuinness suggested that we include
 >>> grant_type as a return claim, which the RS could use to the same
 >> effect*. I
 >>> find the proposal very clever, and the people at IIW thought so as
 well.
 >>> What you think?
 >> The grant type is not something that the RS is really concerned
 with, or
 >> should be. Introducing this parameter in the access token will
 create an
 >> additional logical dependency, plus complexity - in the system of
 >> client, AS and RS as a whole, as well as for RS developers. The grant
 >> type, as a concept, is a matter between the client and AS, and IMO
 >> should stay that way.
 >>
 >> Clear language in the spec should suffice. For instance: "If the sub
 >> value matches the client_id value, then the subject is the client
 >> application".
 >>
 >> Vladimir
 >>
 >> --
 >> Vladimir Dzhuvinov
 >>
 >>
 >> ___
 >> OAuth mailing list
 >> OAuth@ietf.org
 >> https://www.ietf.org/mailman/listinfo/oauth
 >>
 --
 Vladimir Dzhuvinov


 ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>>
>>
>> --
>> hans.zandb...@zmartzone.eu
>> ZmartZone IAM - www.zmartzone.eu
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>

-- 
hans.zandb...@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

See below, Hans- the sub doesn’t have to be global, it could be something
generated just for this particular RS. Or the AS might have its own recipe
for generating sub values that different from the recipe used to generate
client_ids. It would be much easier for an AS to emit a claim making this
explicit statement than to change sub and client_id assignment logic.

On Mon, May 6, 2019 at 13:49 Hans Zandbelt 
wrote:

> I may be missing something but I'd argue that by requiring and comparing
> both "sub" and "client_id" we achieve the same semantics without a
> new/additional claim (barring name spacing)
>
> Hans.
>
> On Mon, May 6, 2019 at 8:58 PM Karl McGuinness  40okta@dmarc.ietf.org> wrote:
>
>> Makes sense that we don’t want to further couple AS and RS with grant
>> types.  I’m OK if we want a dedicated claim to establish whether the token
>> is resource owner delegated  vs client acting as itself.
>>
>> Subject Type is already a concept in RISC.  Just making folks are aware
>> of prior art.
>>
>> https://openid.net/specs/oauth-event-types-1_0-01.html#rfc.section.2.2
>> https://openid.net/specs/openid-risc-profile-1_0.html#rfc.section.2.1
>>
>> -Karl
>>
>> On May 6, 2019, at 12:42 PM, Vittorio Bertocci <
>> Vittorio=40auth0@dmarc.ietf.org> wrote:
>>
>> *This message originated outside your organization.*
>> --
>> Fair enough! What others think about it?
>> Exploring the approach: would we want a bool claim or an enumeration,
>> e.g. sub_type = [ resource_owner | client ] ?
>>
>>
>> On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov <
>> vladi...@connect2id.com> wrote:
>>
>>> Hi Vittorio,
>>>
>>> On 06/05/2019 22:22, Vittorio Bertocci wrote:
>>> > It is true that the grant_type is a client side consideration. I did
>>> think
>>> > about the "client_id==sub" heuristic, but that's not always applicable:
>>> > many systems have their own rules for generating sub, and in case they
>>> want
>>> > to prevent tracking across RSes the sub might be generated ad-hoc for
>>> that
>>> > particular RS.
>>> > Would you prefer to have a dedicated claim that distinguish between
>>> user
>>> > and app tokens rather than reusing grant_type?
>>>
>>> A dedicated claim to flag client_id effectively == sub would be
>>> preferable, and much easier for RS developers to process.
>>>
>>> The AS is the authority and has all the knowledge to set / indicate this.
>>>
>>> I want to keep RS developers away from having to deal with grant types
>>> and having to make decisions whether client_id effectively == sub.
>>>
>>> Vladimir
>>>
>>>
>>> > On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov <
>>> vladi...@connect2id.com>
>>> > wrote:
>>> >
>>> >> On 06/05/2019 20:32, Vittorio Bertocci wrote:
>>> >>> To that end, *Karl MCGuinness suggested that we include
>>> >>> grant_type as a return claim, which the RS could use to the same
>>> >> effect*. I
>>> >>> find the proposal very clever, and the people at IIW thought so as
>>> well.
>>> >>> What you think?
>>> >> The grant type is not something that the RS is really concerned with,
>>> or
>>> >> should be. Introducing this parameter in the access token will create
>>> an
>>> >> additional logical dependency, plus complexity - in the system of
>>> >> client, AS and RS as a whole, as well as for RS developers. The grant
>>> >> type, as a concept, is a matter between the client and AS, and IMO
>>> >> should stay that way.
>>> >>
>>> >> Clear language in the spec should suffice. For instance: "If the sub
>>> >> value matches the client_id value, then the subject is the client
>>> >> application".
>>> >>
>>> >> Vladimir
>>> >>
>>> >> --
>>> >> Vladimir Dzhuvinov
>>> >>
>>> >>
>>> >> ___
>>> >> OAuth mailing list
>>> >> OAuth@ietf.org
>>> >> https://www.ietf.org/mailman/listinfo/oauth
>>> >>
>>> --
>>> Vladimir Dzhuvinov
>>>
>>>
>>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>>
>
> --
> hans.zandb...@zmartzone.eu
> ZmartZone IAM - www.zmartzone.eu
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

2019-05-06 Thread Hans Zandbelt

I may be missing something but I'd argue that by requiring and comparing
both "sub" and "client_id" we achieve the same semantics without a
new/additional claim (barring name spacing)

Hans.

On Mon, May 6, 2019 at 8:58 PM Karl McGuinness  wrote:

> Makes sense that we don’t want to further couple AS and RS with grant
> types.  I’m OK if we want a dedicated claim to establish whether the token
> is resource owner delegated  vs client acting as itself.
>
> Subject Type is already a concept in RISC.  Just making folks are aware of
> prior art.
>
> https://openid.net/specs/oauth-event-types-1_0-01.html#rfc.section.2.2
> https://openid.net/specs/openid-risc-profile-1_0.html#rfc.section.2.1
>
> -Karl
>
> On May 6, 2019, at 12:42 PM, Vittorio Bertocci <
> Vittorio=40auth0@dmarc.ietf.org> wrote:
>
> *This message originated outside your organization.*
> --
> Fair enough! What others think about it?
> Exploring the approach: would we want a bool claim or an enumeration, e.g..
> sub_type = [ resource_owner | client ] ?
>
>
> On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov <
> vladi...@connect2id.com> wrote:
>
>> Hi Vittorio,
>>
>> On 06/05/2019 22:22, Vittorio Bertocci wrote:
>> > It is true that the grant_type is a client side consideration. I did
>> think
>> > about the "client_id==sub" heuristic, but that's not always applicable:
>> > many systems have their own rules for generating sub, and in case they
>> want
>> > to prevent tracking across RSes the sub might be generated ad-hoc for
>> that
>> > particular RS.
>> > Would you prefer to have a dedicated claim that distinguish between user
>> > and app tokens rather than reusing grant_type?
>>
>> A dedicated claim to flag client_id effectively == sub would be
>> preferable, and much easier for RS developers to process.
>>
>> The AS is the authority and has all the knowledge to set / indicate this..
>>
>> I want to keep RS developers away from having to deal with grant types
>> and having to make decisions whether client_id effectively == sub.
>>
>> Vladimir
>>
>>
>> > On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov <
>> vladi...@connect2id.com>
>> > wrote:
>> >
>> >> On 06/05/2019 20:32, Vittorio Bertocci wrote:
>> >>> To that end, *Karl MCGuinness suggested that we include
>> >>> grant_type as a return claim, which the RS could use to the same
>> >> effect*. I
>> >>> find the proposal very clever, and the people at IIW thought so as
>> well.
>> >>> What you think?
>> >> The grant type is not something that the RS is really concerned with,
>> or
>> >> should be. Introducing this parameter in the access token will create
>> an
>> >> additional logical dependency, plus complexity - in the system of
>> >> client, AS and RS as a whole, as well as for RS developers. The grant
>> >> type, as a concept, is a matter between the client and AS, and IMO
>> >> should stay that way.
>> >>
>> >> Clear language in the spec should suffice. For instance: "If the sub
>> >> value matches the client_id value, then the subject is the client
>> >> application".
>> >>
>> >> Vladimir
>> >>
>> >> --
>> >> Vladimir Dzhuvinov
>> >>
>> >>
>> >> ___
>> >> OAuth mailing list
>> >> OAuth@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/oauth
>> >>
>> --
>> Vladimir Dzhuvinov
>>
>>
>> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
hans.zandb...@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

2019-05-06 Thread Karl McGuinness

Makes sense that we don’t want to further couple AS and RS with grant types.  
I’m OK if we want a dedicated claim to establish whether the token is resource 
owner delegated  vs client acting as itself.

Subject Type is already a concept in RISC.  Just making folks are aware of 
prior art.

https://openid.net/specs/oauth-event-types-1_0-01.html#rfc.section.2.2
https://openid.net/specs/openid-risc-profile-1_0.html#rfc.section.2.1

-Karl

On May 6, 2019, at 12:42 PM, Vittorio Bertocci 
mailto:Vittorio=40auth0@dmarc.ietf.org>>
 wrote:

This message originated outside your organization.

Fair enough! What others think about it?
Exploring the approach: would we want a bool claim or an enumeration, e.g. 
sub_type = [ resource_owner | client ] ?


On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov 
mailto:vladi...@connect2id.com>> wrote:
Hi Vittorio,

On 06/05/2019 22:22, Vittorio Bertocci wrote:
> It is true that the grant_type is a client side consideration. I did think
> about the "client_id==sub" heuristic, but that's not always applicable:
> many systems have their own rules for generating sub, and in case they want
> to prevent tracking across RSes the sub might be generated ad-hoc for that
> particular RS.
> Would you prefer to have a dedicated claim that distinguish between user
> and app tokens rather than reusing grant_type?

A dedicated claim to flag client_id effectively == sub would be
preferable, and much easier for RS developers to process.

The AS is the authority and has all the knowledge to set / indicate this.

I want to keep RS developers away from having to deal with grant types
and having to make decisions whether client_id effectively == sub.

Vladimir


> On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov 
> mailto:vladi...@connect2id.com>>
> wrote:
>
>> On 06/05/2019 20:32, Vittorio Bertocci wrote:
>>> To that end, *Karl MCGuinness suggested that we include
>>> grant_type as a return claim, which the RS could use to the same
>> effect*. I
>>> find the proposal very clever, and the people at IIW thought so as well.
>>> What you think?
>> The grant type is not something that the RS is really concerned with, or
>> should be. Introducing this parameter in the access token will create an
>> additional logical dependency, plus complexity - in the system of
>> client, AS and RS as a whole, as well as for RS developers. The grant
>> type, as a concept, is a matter between the client and AS, and IMO
>> should stay that way.
>>
>> Clear language in the spec should suffice. For instance: "If the sub
>> value matches the client_id value, then the subject is the client
>> application".
>>
>> Vladimir
>>
>> --
>> Vladimir Dzhuvinov
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
--
Vladimir Dzhuvinov


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

On 06/05/2019 22:26, Vittorio Bertocci wrote:
> I am not following, Vladimir. What do you mean? Can you make some examples
> to clarify?
> The userinfo is always colocated with the AS, hence I would expect most
> vendors not to use JWT for the ATs issued for userinfo access

That's what I was curious about, if there are any deployments with the
UserInfo not being co-located.

OpenID Connect also has this exotic use case, called distributed claims:

https://openid.net/specs/openid-connect-core-1_0.html#DistributedExample

If co-location is the common case, then there's really no need to spec a
JWT claim for that.

Vladimir


> On Mon, May 6, 2019 at 12:21 PM Vladimir Dzhuvinov 
> wrote:
>
>> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00#section-2.2.2
>>
>> In OpenID Connect the access token is consumed by the UserInfo endpoint.
>>
>> Were there any suggestions to also spec parameter(s) for the claims
>> names (with optional locales) for release at the UserInfo endpoint?
>>
>> Vladimir
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

Fair enough! What others think about it?
Exploring the approach: would we want a bool claim or an enumeration, e.g.
sub_type = [ resource_owner | client ] ?


On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov 
wrote:

> Hi Vittorio,
>
> On 06/05/2019 22:22, Vittorio Bertocci wrote:
> > It is true that the grant_type is a client side consideration. I did
> think
> > about the "client_id==sub" heuristic, but that's not always applicable:
> > many systems have their own rules for generating sub, and in case they
> want
> > to prevent tracking across RSes the sub might be generated ad-hoc for
> that
> > particular RS.
> > Would you prefer to have a dedicated claim that distinguish between user
> > and app tokens rather than reusing grant_type?
>
> A dedicated claim to flag client_id effectively == sub would be
> preferable, and much easier for RS developers to process.
>
> The AS is the authority and has all the knowledge to set / indicate this.
>
> I want to keep RS developers away from having to deal with grant types
> and having to make decisions whether client_id effectively == sub.
>
> Vladimir
>
>
> > On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov <
> vladi...@connect2id.com>
> > wrote:
> >
> >> On 06/05/2019 20:32, Vittorio Bertocci wrote:
> >>> To that end, *Karl MCGuinness suggested that we include
> >>> grant_type as a return claim, which the RS could use to the same
> >> effect*. I
> >>> find the proposal very clever, and the people at IIW thought so as
> well.
> >>> What you think?
> >> The grant type is not something that the RS is really concerned with, or
> >> should be. Introducing this parameter in the access token will create an
> >> additional logical dependency, plus complexity - in the system of
> >> client, AS and RS as a whole, as well as for RS developers. The grant
> >> type, as a concept, is a matter between the client and AS, and IMO
> >> should stay that way.
> >>
> >> Clear language in the spec should suffice. For instance: "If the sub
> >> value matches the client_id value, then the subject is the client
> >> application".
> >>
> >> Vladimir
> >>
> >> --
> >> Vladimir Dzhuvinov
> >>
> >>
> >> ___
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> --
> Vladimir Dzhuvinov
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

Hi Vittorio,

On 06/05/2019 22:22, Vittorio Bertocci wrote:
> It is true that the grant_type is a client side consideration. I did think
> about the "client_id==sub" heuristic, but that's not always applicable:
> many systems have their own rules for generating sub, and in case they want
> to prevent tracking across RSes the sub might be generated ad-hoc for that
> particular RS.
> Would you prefer to have a dedicated claim that distinguish between user
> and app tokens rather than reusing grant_type?

A dedicated claim to flag client_id effectively == sub would be
preferable, and much easier for RS developers to process.

The AS is the authority and has all the knowledge to set / indicate this.

I want to keep RS developers away from having to deal with grant types
and having to make decisions whether client_id effectively == sub.

Vladimir


> On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov 
> wrote:
>
>> On 06/05/2019 20:32, Vittorio Bertocci wrote:
>>> To that end, *Karl MCGuinness suggested that we include
>>> grant_type as a return claim, which the RS could use to the same
>> effect*. I
>>> find the proposal very clever, and the people at IIW thought so as well.
>>> What you think?
>> The grant type is not something that the RS is really concerned with, or
>> should be. Introducing this parameter in the access token will create an
>> additional logical dependency, plus complexity - in the system of
>> client, AS and RS as a whole, as well as for RS developers. The grant
>> type, as a concept, is a matter between the client and AS, and IMO
>> should stay that way.
>>
>> Clear language in the spec should suffice. For instance: "If the sub
>> value matches the client_id value, then the subject is the client
>> application".
>>
>> Vladimir
>>
>> --
>> Vladimir Dzhuvinov
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
-- 
Vladimir Dzhuvinov


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

It is true that the grant_type is a client side consideration. I did think
about the "client_id==sub" heuristic, but that's not always applicable:
many systems have their own rules for generating sub, and in case they want
to prevent tracking across RSes the sub might be generated ad-hoc for that
particular RS.
Would you prefer to have a dedicated claim that distinguish between user
and app tokens rather than reusing grant_type?

On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov 
wrote:

> On 06/05/2019 20:32, Vittorio Bertocci wrote:
> > To that end, *Karl MCGuinness suggested that we include
> > grant_type as a return claim, which the RS could use to the same
> effect*. I
> > find the proposal very clever, and the people at IIW thought so as well.
> > What you think?
>
> The grant type is not something that the RS is really concerned with, or
> should be. Introducing this parameter in the access token will create an
> additional logical dependency, plus complexity - in the system of
> client, AS and RS as a whole, as well as for RS developers. The grant
> type, as a concept, is a matter between the client and AS, and IMO
> should stay that way.
>
> Clear language in the spec should suffice. For instance: "If the sub
> value matches the client_id value, then the subject is the client
> application".
>
> Vladimir
>
> --
> Vladimir Dzhuvinov
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

I am not following, Vladimir. What do you mean? Can you make some examples
to clarify?
The userinfo is always colocated with the AS, hence I would expect most
vendors not to use JWT for the ATs issued for userinfo access

On Mon, May 6, 2019 at 12:21 PM Vladimir Dzhuvinov 
wrote:

>
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00#section-2.2.2
>
> In OpenID Connect the access token is consumed by the UserInfo endpoint.
>
> Were there any suggestions to also spec parameter(s) for the claims
> names (with optional locales) for release at the UserInfo endpoint?
>
> Vladimir
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00#section-2.2.2

In OpenID Connect the access token is consumed by the UserInfo endpoint.

Were there any suggestions to also spec parameter(s) for the claims
names (with optional locales) for release at the UserInfo endpoint?

Vladimir

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

On 06/05/2019 20:32, Vittorio Bertocci wrote:
> To that end, *Karl MCGuinness suggested that we include
> grant_type as a return claim, which the RS could use to the same effect*. I
> find the proposal very clever, and the people at IIW thought so as well.
> What you think?

The grant type is not something that the RS is really concerned with, or
should be. Introducing this parameter in the access token will create an
additional logical dependency, plus complexity - in the system of
client, AS and RS as a whole, as well as for RS developers. The grant
type, as a concept, is a matter between the client and AS, and IMO
should stay that way.

Clear language in the spec should suffice. For instance: "If the sub
value matches the client_id value, then the subject is the client
application".

Vladimir

-- 
Vladimir Dzhuvinov

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

Hi all,
thanks for your patience during this month long hiatus, and thanks for the
comments.
Last week at IIW I had the opportunity to discuss this with many of the
people on the list. Here's a summary of where the discussion landaed on the
subject of the sub (pun intended).

- It seems that RFC 7519 has pretty clear language on the use of sub- I
didn't check it back when we started the discussion. I do agree with the
people saying that we shouldn't violate existing specifications, hence it
looks like we do need to have sub also in the case in which we have
app-only tokens carrying claims about the app itself. I understand this
will cause some implementation to break, but unfortunately that's intrinsic
in the process of coming up with a common approach and standards compliance
is probably one of the strongest reasons to tolerate that.
- That said, I am strongly committed to preserve existing functionality.
One of the main reasons that was brought up for including sub only for user
based ATs was to use it as heuristic for telling those tokens apart from
app-only ones. To that end, *Karl MCGuinness suggested that we include
grant_type as a return claim, which the RS could use to the same effect*. I
find the proposal very clever, and the people at IIW thought so as well.
What you think?
Note, *John Bradley* observed that in some cases this might lead to
ambiguous results if an extension grant is used (say an assertion profile)
but that seems like a relatively fringe occurrence.

On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt 
wrote:

> I also meant to say that (of course) the JWT standard doesn't say that the
> JWT is supposed to be about the client or about the resource owner, hence
> both are valid
>
> Hans.
>
> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones 
> wrote:
>
>> I get that existing practice is likely to be all over the map, but if
>> we’re to create a JWT access token standard, it’s reasonable to require
>> that the claims usage comply with the JWT standards.
>>
>>
>>
>> -- Mike
>>
>>
>>
>> *From:* Hans Zandbelt 
>> *Sent:* Thursday, April 4, 2019 12:59 PM
>> *To:* Mike Jones 
>> *Cc:* George Fletcher > <40aol@dmarc..ietf.org>>; Vittorio Bertocci > 40auth0@dmarc.ietf.org>; IETF oauth WG 
>> *Subject:* Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>>
>>
>>
>> the definition of RFC 7519 is actually "petitio principii" and a lot of
>> deployments put claims about the Resource Owner in the access token (as a
>> Resource Server implementer I've suffered a lot from this)
>>
>>
>>
>> Hans.
>>
>>
>>
>> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones 
>> wrote:
>>
>> I agree with George that the subject of a token must be the principal of
>> that token.  That what the JWT “sub” claim is for.  Indeed, the first
>> sentence of the “sub” definition at
>> https://tools.ietf.org/html/rfc7519#section-4.1.2 is:
>>
>> The "sub" (subject) claim identifies the principal that is the subject of
>> the JWT.
>>
>>
>>
>> If an access token uses “sub”, its usage must comply with the definition
>> from RFC 7519.
>>
>>
>>
>> -- Mike
>>
>>
>>
>> *From:* OAuth  *On Behalf Of *George Fletcher
>> *Sent:* Thursday, April 4, 2019 8:51 AM
>> *To:* Hans Zandbelt 
>> *Cc:* Vittorio Bertocci ; IETF
>> oauth WG 
>> *Subject:* Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>>
>>
>>
>> The more I think about this the more I land in the "No" camp.
>>
>> The subject of a token should be the principal of that token. It
>> shouldn't matter whether that is a machine, a user, or a device. Trying to
>> separate out "humans" as a special class will just make things more
>> complicated. If we need a claim to identify the subject is a "human" then
>> why not just add that. This doesn't break anything and makes it easy for
>> people to detect this case in those use cases where it's required.
>>
>> Thanks,
>> George
>>
>> On 4/3/19 4:56 PM, Hans Zandbelt wrote:
>>
>> I will argue that in a way such deployments are already broken e.g. in
>> the typical use case of onboarding client accounts in the same
>> directory/OU/namespace as user accounts and we don't need to cater for
>> that.
>>
>>
>>
>> Hans.
>>
>>
>>
>> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher  wrote:
>>
>> I agree that this will bre

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

2019-04-08 Thread Brian Campbell

"quotes my own articles on the matter extensively" - I know and almost
mentioned that but didn't want to further embolden your ego :)

Silence is rarely assent. Especially near the end of the last session of
the last day of a workshop. And when I've got a train to catch.

I am somewhat sympathetic to the "... more reasons to provide guidance on
how to do so being aware of pitfalls ... " line of reasoning. But I'd
already indicated my intent to not fight you on this one anymore so that
doesn't change much. Carry on then.



On Thu, Apr 4, 2019 at 11:20 AM Vittorio Bertocci  wrote:

> But before I get in the details, let me make an uber-point..
> I am acutely aware of the potential for confusion and abuse in the context
> of OAuth and sign in, the article you pointed to quotes my own articles on
> the matter extensively. But there are concrete aspects that need to be
> considered about what developers are trying to achieve in practice.
> OAuth2 is the de facto mechanism to secure API calls nowadays. That
> includes scenarios not directly addressed by the spec, such as first party
> APIs. People do that for 1st party APIs as well because they can leverage a
> well supported mechanism for driving authentication experiences and
> outsource authentication to products and services.
> Forgetting for a second about the fact that 3rd party APIs can use
> identity and authentication levels info as well, let me focus for a second
> on 1st party APIs. From the functionality perspective, delivering an app as
> a web site or as a native client+API combination doesn't change the
> business requirements and the information a backend needs to do its job.
> Given that we tell people NOT to use ID tokens for calling APIs: if a
> developer chooses to deliver their app as a native client+API instead of a
> web site, the only artifact they have available is the access token. So
> either we embed the info in the access token, and we do what we can to
> prevent abuse and the most likely pitfalls/privacy challenges/etc in the
> guidance, or we find a way for 1st party APIs to consume ID tokens (which
> is problematic- I discussed this with John and Nat at OSW and the place we
> got stuck on was that we can; safely use sender constrain in that
> scenario). And to pre-empt comments on userinfo, that's asking for a lot of
> extra moving parts- the only outcome will be that people will keep
> embedding the info they need in the AT, but will do so in non-interoperable
> way, and without the guidance and warnings that would at least contain some
> of the damage.
>
> That said, inline.
>
> My concern isn't with reusing the names/types of the claims per se.  But
>> more generally that codifying the use of certain authentication-centric
>> claims in the context of an access token furthers the potential confusion
>> around authentication vs. authorization that has been a nagging problem for
>> OAuth (i.e. the https://oauth.net/articles/authentication/ article).
>
> see preamble.
>
> I  understand what you are saying but but personally do not find it
>> sufficiently compelling.  But that's just my opinion and not a hill I want
>> to die on (at the present time anyway)..
>
> Noted :) does the fact that in some scenarios the AT might be the *only*
> artifact a backend will receive change the stance?
>
>  By the time it came up again near the end of the last unconference
>> session, I wasn't wanting to prolong things because I was kinda worn out
>> for the day and wanting to get to Frankfurt that evening before sunset
>> ('cause I like to do stuff like this: https://flic.kr/p/2fiAaPe :) ).
>
> Sorry for having tired you out :) at the time I echoed back what was
> suggested (to reflect the original values in the session) precisely to make
> sure everyone had a chance to push back, and I got lots of nods (including
> from John who was in the first row). I misinterpreted your silence as
> assent, given that during that session you did chime in on other matters...
> but I was expecting the discussion to keep going on the ML anyway, so it's
> all according to plan :)
>
>  FWIW, to me, George's suggestion "assume[ing] that the auth_time value
>> should be updated to the latest time at which the user authenticated"
>> though some unspecified and in many cases non-existent link between the AT
>> and a current user session at the AS is an example of how
>> authentication-centric claims in an access token can be confusing.
>
>  I agree it can be confusing, but to me that makes the need to provide
> guidance on it more compelling, not less. There are important scenarios
> where access decisions are made on the basis of that information, and
> implementations WILL find a way to get the info they are interested into.
> To me that's all the more reasons to provide guidance on how to do so being
> aware of pitfalls and with whatever protections we can put in place, as
> opposed to leave developers to their own device.
>
> On Thu, Apr 4, 2019 at 9:32 AM Brian

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

2019-04-05 Thread Binningsbø , Jørgen

Hi,



We have a machine-to-machine scenario where clients, RSes and our AS all belong 
to different legal entities.



Some RSes require their clients to limit the access token to a specific 
Resource Owner, while other RSes don't. In the former case, we use 'sub' to 
identify that Resource Owner.  In such a mixed deployment scenario, allowing 
using 'sub' for different meanings can lead to confusion, so I think the actual 
meaning should be explicitly signalled like Dave suggests below.



Having said that, I do prefer to limit the usage of 'sub' in access tokens for 
the End User only.





As a side note, in our case we need a more formal client identification than 
the client_id alone (as they are randomly generated by DCR),  and have thus 
opted for a custom claim `client_owner` containing the registered company 
identifier.  We pull this out from certificate used to sign the JWT-grant 
(RFC7523) from the token request.   We could of course have used ‘sub’ for 
client_owner, but that would require us to invent another custom claim for 
those RSes that requires RO-limited tokens.To make matters even more 
complicated, there might be business delegation happening,  where company A 
running the client is acting on behalf of different other companies B,C,D… and 
the instantaneous A+B or A+C relation also have to be communicated in the token 
 (According to EU privacy laws, I belive A is the Data Processor and their 
customer B,C,D… are Data Controller).   So again this leads me to think that 
client identification should be kept in separate claims.



Anyway, for us as user of the oauth2 protocols, this draft is welcome !





Kind regards,
--
Jørgen Binningsbø
Product Owner, Norwegian National eID Infrastructure (ID-porten)

Fra: OAuth  På vegne av Dave Tonge
Sendt: tirsdag 26. mars 2019 09.27
Til: Dominick Baier 
Kopi: IETF oauth WG 
Emne: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

Thanks Vittorio for your presentation and putting this draft together.

I agree with Dominck that there is a potential of things going wrong when `sub` 
has multiple meanings.
However I can see that using `sub` for a client_id semantically makes sense in 
some situations and I agree that it makes it simpler from an SDK point of view 
for there to always be a `sub`.

My suggestion would be that either there is an explicit type to differentiate 
between "user access tokens" and "application access tokens", or failing that 
the `sub` is used to indicate the difference.

Furthermore an agreement on the naming and description of these two types of 
access tokens would be helpful more generally.

Dave

On Tue, 26 Mar 2019 at 07:25, Dominick Baier 
mailto:dba...@leastprivilege.com>> wrote:
From an access token consumer (aka API) developer point of view, I prefer this 
logic

"If sub is present - client acts on behalf of a user, if not - not."

Anything more complicated has a potential of going wrong.



On 26. March 2019 at 01:34:53, Nov Matake 
(mat...@gmail.com<mailto:mat...@gmail.com>) wrote:
Hi Vittorio,

Yeah, I’m concerning user & client ids collision.
I haven’t seen such implementations, but user-select username as sub, or 
incremental integer as sub & client_id will be easily collide.

If you can enforce collision resistant IDs between user & client instances, 
it’ll works fine. I feel its overkill though.

Sent from my iPhone

On Mar 26, 2019, at 8:51, Vittorio Bertocci 
mailto:vitto...@auth0.com>> wrote:
Hey Nov, Dominick, Hans-
thanks for the comments. That was an area I was expecting to cause more 
discussion, and I am glad we are having this opportunity to clarify.
The current language in the draft traces the etymology of sub to OpenID Connect 
core, hence Dominick observation is on point. However in the description I 
express something in line with 7519, which was in fact my intent.

The idea was to provide an identifier of the calling subject that is guaranteed 
to be present in all cases- this would allow an SDK developer to use the same 
code for things like lookups and membership checks regardless of the nature of 
the caller (user in a delegated case, app in app-only grants). The information 
to discriminate between user and app callers is always available in the token 
(say, the caller is a user if sub!=client_id, where client_id is always 
guaranteed to be present as well) hence there's no loss in expressive power, 
should that difference be relevant for the resource server.

Dominick, Hans- I probably missed the security issue you guys are thinking of 
in this case. Of course, if this would introduce a risk I completely agree it 
should be changed- I'd just like to understand better the problem. Could you 
expand it in a scenario/use case to clarify the risk?
Nov- playing this back: is the concern that a user and a client might have the 
same identifier within an IDP? When using collision resistant IDs, as it is 
usually the

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

I also meant to say that (of course) the JWT standard doesn't say that the
JWT is supposed to be about the client or about the resource owner, hence
both are valid

Hans.

On Thu, Apr 4, 2019 at 10:09 PM Mike Jones 
wrote:

> I get that existing practice is likely to be all over the map, but if
> we’re to create a JWT access token standard, it’s reasonable to require
> that the claims usage comply with the JWT standards.
>
>
>
> -- Mike
>
>
>
> *From:* Hans Zandbelt 
> *Sent:* Thursday, April 4, 2019 12:59 PM
> *To:* Mike Jones 
> *Cc:* George Fletcher ; Vittorio
> Bertocci ; IETF oauth WG <
> oauth@ietf.org>
> *Subject:* Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>
>
>
> the definition of RFC 7519 is actually "petitio principii" and a lot of
> deployments put claims about the Resource Owner in the access token (as a
> Resource Server implementer I've suffered a lot from this)
>
>
>
> Hans.
>
>
>
> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones 
> wrote:
>
> I agree with George that the subject of a token must be the principal of
> that token.  That what the JWT “sub” claim is for.  Indeed, the first
> sentence of the “sub” definition at
> https://tools.ietf.org/html/rfc7519#section-4.1.2 is:
>
> The "sub" (subject) claim identifies the principal that is the subject of
> the JWT.
>
>
>
> If an access token uses “sub”, its usage must comply with the definition
> from RFC 7519.
>
>
>
> -- Mike
>
>
>
> *From:* OAuth  *On Behalf Of *George Fletcher
> *Sent:* Thursday, April 4, 2019 8:51 AM
> *To:* Hans Zandbelt 
> *Cc:* Vittorio Bertocci ; IETF oauth
> WG 
> *Subject:* Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>
>
>
> The more I think about this the more I land in the "No" camp.
>
> The subject of a token should be the principal of that token. It shouldn't
> matter whether that is a machine, a user, or a device. Trying to separate
> out "humans" as a special class will just make things more complicated. If
> we need a claim to identify the subject is a "human" then why not just add
> that. This doesn't break anything and makes it easy for people to detect
> this case in those use cases where it's required.
>
> Thanks,
> George
>
> On 4/3/19 4:56 PM, Hans Zandbelt wrote:
>
> I will argue that in a way such deployments are already broken e.g. in the
> typical use case of onboarding client accounts in the same
> directory/OU/namespace as user accounts and we don't need to cater for
> that.
>
>
>
> Hans.
>
>
>
> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher  wrote:
>
> I agree that this will break a lot of existing flows... especially those
> using any form of the client_credentials flow. In that sense I'm not
> completely on board yet :)
>
> On 3/26/19 12:56 PM, Hans Zandbelt wrote:
>
> great summary! this will hurt quite a few existing m2m deployments but I
> do like the rigidness of it all: it is very explicit, cannot misinterpreted
> and thus prevents failure (which is really what Dominick is after); I'm on
> board
>
>
>
> Hans.
>
>
>
> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci  40auth0@dmarc.ietf.org> wrote:
>
> thank you Steinar and everyone else for the comments on this!
>
> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov,
> Bertrand recommend using sub only for users. Martin would like to have the
> sub for app only flows as well. Hans is neutral.
>
> That does sound like the sub as user has more consensus, tho before
> changing it I'd wait for the people currently at IETF104 to have more time
> to comment as well.
>
> Clarification. If the goal is to be able to apply the logic "if there's a
> sub, it's a user flow", we have to explicitly disallow (MUST NOT) the use
> of sub when that's not the case. Are all OK with it?
>
>
>
> Dave, the suggestion of having explicit typing for app only vs user only
> is interesting! For the purpose of putting together an interoperable
> profile, tho, I would suggest we table it for v1 in the interest of getting
> to something easy to adopt (hence with small delta vs existing
> implementations) faster.
>
>
>
> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem  wrote:
>
> Hi Vittorio, we  (the national federation-gateway for the health services
> in norway - "HelseID")  think his is a really valuable initiative!
>
> We also agree with Dominick concerning definition of the "sub" claim.
>
>

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

2019-04-04 Thread Mike Jones

I get that existing practice is likely to be all over the map, but if we’re to 
create a JWT access token standard, it’s reasonable to require that the claims 
usage comply with the JWT standards.

-- Mike

From: Hans Zandbelt 
Sent: Thursday, April 4, 2019 12:59 PM
To: Mike Jones 
Cc: George Fletcher ; Vittorio Bertocci 
; IETF oauth WG 
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

the definition of RFC 7519 is actually "petitio principii" and a lot of 
deployments put claims about the Resource Owner in the access token (as a 
Resource Server implementer I've suffered a lot from this)

Hans.

On Thu, Apr 4, 2019 at 9:48 PM Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
I agree with George that the subject of a token must be the principal of that 
token.  That what the JWT “sub” claim is for.  Indeed, the first sentence of 
the “sub” definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 is:
The "sub" (subject) claim identifies the principal that is the subject of the 
JWT.

If an access token uses “sub”, its usage must comply with the definition from 
RFC 7519.

-- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of George Fletcher
Sent: Thursday, April 4, 2019 8:51 AM
To: Hans Zandbelt 
mailto:hans.zandb...@zmartzone.eu>>
Cc: Vittorio Bertocci 
mailto:40auth0@dmarc.ietf.org>>; IETF 
oauth WG mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

The more I think about this the more I land in the "No" camp.

The subject of a token should be the principal of that token. It shouldn't 
matter whether that is a machine, a user, or a device. Trying to separate out 
"humans" as a special class will just make things more complicated. If we need 
a claim to identify the subject is a "human" then why not just add that. This 
doesn't break anything and makes it easy for people to detect this case in 
those use cases where it's required.

Thanks,
George
On 4/3/19 4:56 PM, Hans Zandbelt wrote:
I will argue that in a way such deployments are already broken e.g. in the 
typical use case of onboarding client accounts in the same 
directory/OU/namespace as user accounts and we don't need to cater for that.

Hans.

On Wed, Apr 3, 2019 at 10:48 PM George Fletcher 
mailto:gffle...@aol.com>> wrote:
I agree that this will break a lot of existing flows... especially those using 
any form of the client_credentials flow. In that sense I'm not completely on 
board yet :)
On 3/26/19 12:56 PM, Hans Zandbelt wrote:
great summary! this will hurt quite a few existing m2m deployments but I do 
like the rigidness of it all: it is very explicit, cannot misinterpreted and 
thus prevents failure (which is really what Dominick is after); I'm on board

Hans.

On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci 
mailto:40auth0@dmarc.ietf.org>> wrote:
thank you Steinar and everyone else for the comments on this!
To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, Bertrand 
recommend using sub only for users. Martin would like to have the sub for app 
only flows as well. Hans is neutral.
That does sound like the sub as user has more consensus, tho before changing it 
I'd wait for the people currently at IETF104 to have more time to comment as 
well.
Clarification. If the goal is to be able to apply the logic "if there's a sub, 
it's a user flow", we have to explicitly disallow (MUST NOT) the use of sub 
when that's not the case. Are all OK with it?

Dave, the suggestion of having explicit typing for app only vs user only is 
interesting! For the purpose of putting together an interoperable profile, tho, 
I would suggest we table it for v1 in the interest of getting to something easy 
to adopt (hence with small delta vs existing implementations) faster.

On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem 
mailto:stei...@udelt.no>> wrote:
Hi Vittorio, we  (the national federation-gateway for the health services in 
norway - "HelseID")  think his is a really valuable initiative!
We also agree with Dominick concerning definition of the "sub" claim.

Steinar

tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier 
mailto:dba...@leastprivilege.com>>:
From an access token consumer (aka API) developer point of view, I prefer this 
logic

"If sub is present - client acts on behalf of a user, if not - not."

Anything more complicated has a potential of going wrong.

On 26. March 2019 at 01:34:53, Nov Matake 
(mat...@gmail.com<mailto:mat...@gmail.com>) wrote:
Hi Vittorio,

Yeah, I’m concerning user & client ids collision.
I haven’t seen such implementations, but user-select username as sub, or 
incremental integer as sub & client_id will be easily collide.

If you can

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

the definition of RFC 7519 is actually "petitio principii" and a lot of
deployments put claims about the Resource Owner in the access token (as a
Resource Server implementer I've suffered a lot from this)

Hans.

On Thu, Apr 4, 2019 at 9:48 PM Mike Jones 
wrote:

> I agree with George that the subject of a token must be the principal of
> that token.  That what the JWT “sub” claim is for.  Indeed, the first
> sentence of the “sub” definition at
> https://tools.ietf.org/html/rfc7519#section-4.1.2 is:
>
> The "sub" (subject) claim identifies the principal that is the subject of
> the JWT.
>
>
>
> If an access token uses “sub”, its usage must comply with the definition
> from RFC 7519.
>
>
>
> -- Mike
>
>
>
> *From:* OAuth  *On Behalf Of *George Fletcher
> *Sent:* Thursday, April 4, 2019 8:51 AM
> *To:* Hans Zandbelt 
> *Cc:* Vittorio Bertocci ; IETF oauth
> WG 
> *Subject:* Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>
>
>
> The more I think about this the more I land in the "No" camp.
>
> The subject of a token should be the principal of that token. It shouldn't
> matter whether that is a machine, a user, or a device. Trying to separate
> out "humans" as a special class will just make things more complicated. If
> we need a claim to identify the subject is a "human" then why not just add
> that. This doesn't break anything and makes it easy for people to detect
> this case in those use cases where it's required.
>
> Thanks,
> George
>
> On 4/3/19 4:56 PM, Hans Zandbelt wrote:
>
> I will argue that in a way such deployments are already broken e.g. in the
> typical use case of onboarding client accounts in the same
> directory/OU/namespace as user accounts and we don't need to cater for
> that.
>
>
>
> Hans.
>
>
>
> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher  wrote:
>
> I agree that this will break a lot of existing flows... especially those
> using any form of the client_credentials flow. In that sense I'm not
> completely on board yet :)
>
> On 3/26/19 12:56 PM, Hans Zandbelt wrote:
>
> great summary! this will hurt quite a few existing m2m deployments but I
> do like the rigidness of it all: it is very explicit, cannot misinterpreted
> and thus prevents failure (which is really what Dominick is after); I'm on
> board
>
>
>
> Hans.
>
>
>
> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci  40auth0@dmarc.ietf.org> wrote:
>
> thank you Steinar and everyone else for the comments on this!
>
> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov,
> Bertrand recommend using sub only for users. Martin would like to have the
> sub for app only flows as well. Hans is neutral.
>
> That does sound like the sub as user has more consensus, tho before
> changing it I'd wait for the people currently at IETF104 to have more time
> to comment as well.
>
> Clarification. If the goal is to be able to apply the logic "if there's a
> sub, it's a user flow", we have to explicitly disallow (MUST NOT) the use
> of sub when that's not the case. Are all OK with it?
>
>
>
> Dave, the suggestion of having explicit typing for app only vs user only
> is interesting! For the purpose of putting together an interoperable
> profile, tho, I would suggest we table it for v1 in the interest of getting
> to something easy to adopt (hence with small delta vs existing
> implementations) faster.
>
>
>
> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem  wrote:
>
> Hi Vittorio, we  (the national federation-gateway for the health services
> in norway - "HelseID")  think his is a really valuable initiative!
>
> We also agree with Dominick concerning definition of the "sub" claim.
>
>
>
> Steinar
>
>
>
> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <
> dba...@leastprivilege.com>:
>
> From an access token consumer (aka API) developer point of view, I prefer
> this logic
>
>
>
> "If sub is present - client acts on behalf of a user, if not - not."
>
>
>
> Anything more complicated has a potential of going wrong.
>
>
>
> On 26. March 2019 at 01:34:53, Nov Matake (mat...@gmail.com) wrote:
>
> Hi Vittorio,
>
>
>
> Yeah, I’m concerning user & client ids collision.
>
> I haven’t seen such implementations, but user-select username as sub, or
> incremental integer as sub & client_id will be easily collide.
>
>
>
> If you can enforce collision resistant IDs between user & client
> instances, it’ll works fine. I feel its over

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

2019-04-04 Thread Mike Jones

I agree with George that the subject of a token must be the principal of that 
token.  That what the JWT “sub” claim is for.  Indeed, the first sentence of 
the “sub” definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 is:
The "sub" (subject) claim identifies the principal that is the subject of the 
JWT.

If an access token uses “sub”, its usage must comply with the definition from 
RFC 7519.

-- Mike

From: OAuth  On Behalf Of George Fletcher
Sent: Thursday, April 4, 2019 8:51 AM
To: Hans Zandbelt 
Cc: Vittorio Bertocci ; IETF oauth WG 

Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

The more I think about this the more I land in the "No" camp.

The subject of a token should be the principal of that token. It shouldn't 
matter whether that is a machine, a user, or a device. Trying to separate out 
"humans" as a special class will just make things more complicated. If we need 
a claim to identify the subject is a "human" then why not just add that. This 
doesn't break anything and makes it easy for people to detect this case in 
those use cases where it's required.

Thanks,
George
On 4/3/19 4:56 PM, Hans Zandbelt wrote:
I will argue that in a way such deployments are already broken e.g. in the 
typical use case of onboarding client accounts in the same 
directory/OU/namespace as user accounts and we don't need to cater for that.

Hans.

On Wed, Apr 3, 2019 at 10:48 PM George Fletcher 
mailto:gffle...@aol.com>> wrote:
I agree that this will break a lot of existing flows... especially those using 
any form of the client_credentials flow. In that sense I'm not completely on 
board yet :)
On 3/26/19 12:56 PM, Hans Zandbelt wrote:
great summary! this will hurt quite a few existing m2m deployments but I do 
like the rigidness of it all: it is very explicit, cannot misinterpreted and 
thus prevents failure (which is really what Dominick is after); I'm on board

Hans.

On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci 
mailto:40auth0@dmarc.ietf.org>> wrote:
thank you Steinar and everyone else for the comments on this!
To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, Bertrand 
recommend using sub only for users. Martin would like to have the sub for app 
only flows as well. Hans is neutral.
That does sound like the sub as user has more consensus, tho before changing it 
I'd wait for the people currently at IETF104 to have more time to comment as 
well.
Clarification. If the goal is to be able to apply the logic "if there's a sub, 
it's a user flow", we have to explicitly disallow (MUST NOT) the use of sub 
when that's not the case. Are all OK with it?

Dave, the suggestion of having explicit typing for app only vs user only is 
interesting! For the purpose of putting together an interoperable profile, tho, 
I would suggest we table it for v1 in the interest of getting to something easy 
to adopt (hence with small delta vs existing implementations) faster.

On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem 
mailto:stei...@udelt.no>> wrote:
Hi Vittorio, we  (the national federation-gateway for the health services in 
norway - "HelseID")  think his is a really valuable initiative!
We also agree with Dominick concerning definition of the "sub" claim.

Steinar

tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier 
mailto:dba...@leastprivilege.com>>:
From an access token consumer (aka API) developer point of view, I prefer this 
logic

"If sub is present - client acts on behalf of a user, if not - not."

Anything more complicated has a potential of going wrong.


On 26. March 2019 at 01:34:53, Nov Matake 
(mat...@gmail.com<mailto:mat...@gmail.com>) wrote:
Hi Vittorio,

Yeah, I’m concerning user & client ids collision.
I haven’t seen such implementations, but user-select username as sub, or 
incremental integer as sub & client_id will be easily collide.

If you can enforce collision resistant IDs between user & client instances, 
it’ll works fine. I feel its overkill though.

Sent from my iPhone

On Mar 26, 2019, at 8:51, Vittorio Bertocci 
mailto:vitto...@auth0.com>> wrote:
Hey Nov, Dominick, Hans-
thanks for the comments. That was an area I was expecting to cause more 
discussion, and I am glad we are having this opportunity to clarify.
The current language in the draft traces the etymology of sub to OpenID Connect 
core, hence Dominick observation is on point. However in the description I 
express something in line with 7519, which was in fact my intent.

The idea was to provide an identifier of the calling subject that is guaranteed 
to be present in all cases- this would allow an SDK developer to use the same 
code for things like lookups and membership checks regardless of the nature of 
the caller (user in a delegated case, app in app-only grants). The information 
to

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

I get your 1st party use case and if you think about a company that
might have multiple endpoints on different domains that provide API
services all invoked by a mobile app... requiring the mobile app to
effectively downscope (or resource indicator bind) tokens means a lot of
chatter between the mobile app to the AS to obtain appropriate tokens.
And all this over a connection that does have latency issues.

That said, having a single token that is authorized to access all those
services has it's own risks.

I'm not sure about a structure like...
https://user.example.com
scope: profile
https://mail.example.com
scope: mail-write
https://cal.example.com
scope: calendar-write

User Managed Access (UMA) [1] explicitly defines this structure but it's
not embedded in the UMA access token.

[1]
https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-05.html#permission-endpoint

I suppose a need to support multiple audiences within a given access
token kind of necessitates the need to bind the scopes with the
audience/resource.

On 4/4/19 1:34 PM, Vittorio Bertocci wrote:

I think for most implementations this would amount to... define an
audience that covers all the resource services where the access
token can be returned and set that as the audience (e.g.
urn:x-mydomain:apis). Which is perfectly legal but maybe not in
the spirit of the spec:) I am receiving feedback from developers
that binding access tokens narrowly to the resource where they
will be presented is concerning from a chattiness perspective
(latency issues) and general load on the deployed AS infrastructure.

This is an interesting point. In my experience, the main boundary used
to define a resource is either reflecting an underlying, *actual*
resource that exists independently of the API facade slapped on top of
it (say a VM) or it is the context within a certains et of scopes
makes sense (say an API facading access to a bunch of documents).
Some of that criterion is reflected in the rationale for sigle value
audiences. Do you think it should be made more explicit? Perhaps in a
dedicated section?

[rest of thread snipped]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

Thanks Martin. Inline

I kind of agree that you might want to have this information in the token,
> if possible. You can save a lot of round trips over time (at the expense of
> revocation).

Yep, this entire profile idea emerged as acknowledgement that a large
number of services and products choose to use format driven validation.

 But then, we should simply take that (rfc7662) as a boilerplate for the
> JWT, not OIDC.
> An introspection response also contains scopes, username and optional
> additional claims (e.g. OIDC / authN specific claims)
>
Ultimately all I care about is that we give guidance to developers on on
how to transport in JWT encoded ATs the info their API need. In the initial
formulation I referred to OIDC because in my experience most of the
existing software being used to consume JWT ATs is largely "jury-rigged"
middleware either meant to be used for id_tokens or reusing infrastructure
meant for OIDC (discovery, etc).
As long as the expressive power is the same, I am happy to switch all the
references from OIDC to rfc7662. Developers won't care either ways as long
as they can get the job done.


> I think an access token JWT should not convey more / other information
> than a token introspection endpoint.

Could you expand on this? Could you make a concrete example of a claim you
can get through OIDC that you would not want included in an AT, and why? I
am especially interested in this from the PoV of the 1st party API scenario
I described earlier: if an AT is all you are getting , it seems you should
be able to get any info you could have gotten otherwise.

On Thu, Apr 4, 2019 at 10:40 AM Schanzenbach, Martin <
martin.schanzenb...@aisec.fraunhofer.de> wrote:

> Hi Vittorio,
>
> > On 4. Apr 2019, at 19:19, Vittorio Bertocci  40auth0@dmarc.ietf.org> wrote:
> >
> > But before I get in the details, let me make an uber-point..
> > I am acutely aware of the potential for confusion and abuse in the
> context of OAuth and sign in, the article you pointed to quotes my own
> articles on the matter extensively. But there are concrete aspects that
> need to be considered about what developers are trying to achieve in
> practice.
> > OAuth2 is the de facto mechanism to secure API calls nowadays. That
> includes scenarios not directly addressed by the spec, such as first party
> APIs. People do that for 1st party APIs as well because they can leverage a
> well supported mechanism for driving authentication experiences and
> outsource authentication to products and services.
> > Forgetting for a second about the fact that 3rd party APIs can use
> identity and authentication levels info as well, let me focus for a second
> on 1st party APIs. From the functionality perspective, delivering an app as
> a web site or as a native client+API combination doesn't change the
> business requirements and the information a backend needs to do its job.
> > Given that we tell people NOT to use ID tokens for calling APIs: if a
> developer chooses to deliver their app as a native client+API instead of a
> web site, the only artifact they have available is the access token. So
> either we embed the info in the access token, and we do what we can to
> prevent abuse and the most likely pitfalls/privacy challenges/etc in the
> guidance, or we find a way for 1st party APIs to consume ID tokens (which
> is problematic- I discussed this with John and Nat at OSW and the place we
> got stuck on was that we can; safely use sender constrain in that scenario).
> > And to pre-empt comments on userinfo, that's asking for a lot of extra
> moving parts- the only outcome will be that people will keep embedding the
> info they need in the AT, but will do so in non-interoperable way, and
> without the guidance and warnings that would at least contain some of the
> damage.
>
> Userinfo is OIDC. Do you mean rfc7662?
> So you say that the use of a token introspection endpoint like rfc7662 is
> not always viable, right?
> I kind of agree that you might want to have this information in the token,
> if possible. You can save a lot of round trips over time (at the expense of
> revocation).
> But then, we should simply take that (rfc7662) as a boilerplate for the
> JWT, not OIDC.
> An introspection response also contains scopes, username and optional
> additional claims (e.g. OIDC / authN specific claims).
> I think an access token JWT should not convey more / other information
> than a token introspection endpoint.
>
> BR
>
> >
> > That said, inline.
> >
> > My concern isn't with reusing the names/types of the claims per se.  But
> more generally that codifying the use of certain authentication-centric
> claims in the context of an access token furthers the potential confusion
> around authentication vs. authorization that has been a nagging problem for
> OAuth (i.e. the https://oauth.net/articles/authentication/ article).
> > see preamble.
> >
> > I  understand what you are saying but but personally do not find it
> sufficiently

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

>
> As an aside, I worry about trying to put all information needed to make a
> dynamic policy decision into an access token.

I am not suggesting any of this would be exhaustive. The intent is to give
guidance on the most commonly used elements, stuff we already know is being
considered. Besides achieving some level of interop, this can help educate
readers on what are the things one typically watch out for- and could lead
to better decisions even for other attributes they choose to add outside of
the scope of this profile.


> For cases where the policy can change over time including the lifetime of
> the access_token then I prefer the User Managed Access (UMA) approach as it
> inherently allows for dynamic policy change

I think simplicity is key here. Having the info available allows developers
to be confident they can enforce their requirements transparently, using
off the shelf software components.

On Thu, Apr 4, 2019 at 7:14 AM George Fletcher  wrote:

> Comments inline...
>
> On 4/3/19 3:38 PM, Vittorio Bertocci wrote:
>
> Thanks guys for the comment, sorry for the delay in addressing them.
> I am not married to the claim types used in here, so if you think that
> reusing the ones in the id_token can cause confusion we should expand on
> the specific ways in which you think might go south.
>
> I'm fine with re-using claims... we just need to make sure if we reuse a
> claim it keeps the same semantic.
>
> However I think it's important that the information on say, whether the
> current token was obtained using MFA or a specific authentication factor is
> something that API developers can legitimately latch to when doing
> authorization decisions. From the perspective of a developer modeling a
> solution, whether functionality is delivered as a route in a postback based
> web app (hence receiving an id_token or derived) or as an API consumed by a
> native app, the business requirement gating access to that functionality
> doesn't change. If the admin managing that resource establishes that access
> should be performed only via MFA, the developer should be equipped to
> enforce that regardless of the stack used to expose functionality (web app,
> API).
> Although it is true that triggering the desired behavior might be achieved
> by the resource setting and contract with the AS, along the lines of what
> David said, it's actually not uncommon for those policies to be assigned on
> the resource AFTER the current session was established and/or the
> corresponding AT was obtained and cached. Furthermore, the requirement
> might be more granular than an AS policy can tolerate (an API might
> requires MFA only for certain routes, hence hard to express in a static
> policy) and triggered in form of challenges. So the situation in which you
> have an AT with the right issuer, audience, etc but was obtained with a
> policy now obsolete/unacceptable to the RP is strong. Requesting to support
> revocation just for this seems overkill, especially given that the scenario
> in which the same logical app is exposed as both web app and native
> client+API, the code consuming those claims is already in place. It just
> makes intuitive sense for developers.
> In summary, one can take steps to push as much of the MFA requirements to
> the AS settings for a particular request, but ultimately the desire of the
> API developer to enforce that it actually happened is a requirement I
> encountered often in practice. Anything providing extra context to refine
> decisions about it (like auth_time, which might inform decisions about
> whether to accept an MFA check occurred N minutes ago or refuse access).
>
> As an aside, I worry about trying to put all information needed to make a
> dynamic policy decision into an access token. For cases where the policy
> can change over time including the lifetime of the access_token then I
> prefer the User Managed Access (UMA) approach as it inherently allows for
> dynamic policy change.
>
>
> I thought that reusing the existing names for the same concepts just made
> sense (dev existing skills, existing codebases, etc etc) and especially in
> the case in which the values are exactly the same, and the idea seemed to
> receive good support during OSW. But I am completely open to change it of
> course, especially for cases like the one identified by George.
> WDYT?
>
> On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
>> +1 to David's question here. I'd like to see justifying use cases (beyond
>> just the fact that some people are already doing it) for auth_time, acr,
>> and amr to be available in OAuth JWT access tokens. Those claims are
>> defined for, and in the context of, an ID Token and I fear that codifying
>> their use in an access token will lead to misuse and/or confusion.
>>
>> On Mon, Apr 1, 2019 at 1:03 PM David Waite 
>> wrote:
>>
>>> Do we know if there is a justifying use case for auth_time, acr, and amr
>>> to be available in

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

2019-04-04 Thread Schanzenbach, Martin

Hi Vittorio,

> On 4. Apr 2019, at 19:19, Vittorio Bertocci 
>  wrote:
> 
> But before I get in the details, let me make an uber-point..
> I am acutely aware of the potential for confusion and abuse in the context of 
> OAuth and sign in, the article you pointed to quotes my own articles on the 
> matter extensively. But there are concrete aspects that need to be considered 
> about what developers are trying to achieve in practice.
> OAuth2 is the de facto mechanism to secure API calls nowadays. That includes 
> scenarios not directly addressed by the spec, such as first party APIs. 
> People do that for 1st party APIs as well because they can leverage a well 
> supported mechanism for driving authentication experiences and outsource 
> authentication to products and services.
> Forgetting for a second about the fact that 3rd party APIs can use identity 
> and authentication levels info as well, let me focus for a second on 1st 
> party APIs. From the functionality perspective, delivering an app as a web 
> site or as a native client+API combination doesn't change the business 
> requirements and the information a backend needs to do its job.
> Given that we tell people NOT to use ID tokens for calling APIs: if a 
> developer chooses to deliver their app as a native client+API instead of a 
> web site, the only artifact they have available is the access token. So 
> either we embed the info in the access token, and we do what we can to 
> prevent abuse and the most likely pitfalls/privacy challenges/etc in the 
> guidance, or we find a way for 1st party APIs to consume ID tokens (which is 
> problematic- I discussed this with John and Nat at OSW and the place we got 
> stuck on was that we can; safely use sender constrain in that scenario).
> And to pre-empt comments on userinfo, that's asking for a lot of extra moving 
> parts- the only outcome will be that people will keep embedding the info they 
> need in the AT, but will do so in non-interoperable way, and without the 
> guidance and warnings that would at least contain some of the damage.

Userinfo is OIDC. Do you mean rfc7662?
So you say that the use of a token introspection endpoint like rfc7662 is not 
always viable, right?
I kind of agree that you might want to have this information in the token, if 
possible. You can save a lot of round trips over time (at the expense of 
revocation).
But then, we should simply take that (rfc7662) as a boilerplate for the JWT, 
not OIDC.
An introspection response also contains scopes, username and optional 
additional claims (e.g. OIDC / authN specific claims).
I think an access token JWT should not convey more / other information than a 
token introspection endpoint.

BR

> 
> That said, inline.
> 
> My concern isn't with reusing the names/types of the claims per se.  But more 
> generally that codifying the use of certain authentication-centric claims in 
> the context of an access token furthers the potential confusion around 
> authentication vs. authorization that has been a nagging problem for OAuth 
> (i.e. the https://oauth.net/articles/authentication/ article).
> see preamble.
> 
> I  understand what you are saying but but personally do not find it 
> sufficiently compelling.  But that's just my opinion and not a hill I want to 
> die on (at the present time anyway)..
> Noted :) does the fact that in some scenarios the AT might be the *only* 
> artifact a backend will receive change the stance?
> 
>  By the time it came up again near the end of the last unconference session, 
> I wasn't wanting to prolong things because I was kinda worn out for the day 
> and wanting to get to Frankfurt that evening before sunset ('cause I like to 
> do stuff like this: https://flic.kr/p/2fiAaPe :) ).
> Sorry for having tired you out :) at the time I echoed back what was 
> suggested (to reflect the original values in the session) precisely to make 
> sure everyone had a chance to push back, and I got lots of nods (including 
> from John who was in the first row). I misinterpreted your silence as assent, 
> given that during that session you did chime in on other matters.. but I was 
> expecting the discussion to keep going on the ML anyway, so it's all 
> according to plan :)
> 
>  FWIW, to me, George's suggestion "assume[ing] that the auth_time value 
> should be updated to the latest time at which the user authenticated" though 
> some unspecified and in many cases non-existent link between the AT and a 
> current user session at the AS is an example of how authentication-centric 
> claims in an access token can be confusing.
>  I agree it can be confusing, but to me that makes the need to provide 
> guidance on it more compelling, not less. There are important scenarios where 
> access decisions are made on the basis of that information, and 
> implementations WILL find a way to get the info they are interested into. To 
> me that's all the more reasons to provide guidance on how to do so being 
> aware of

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

Hey George! Thanks for the comments. nline

The issue here is that the 'aud' of the id_token is the recipient of the
> id_token (i.e. the client). However, for access_tokens the 'aud' value
> should be the resource service that will receive the access_token. There is
> no existing guidance for this and we should provide such guidance as this
> is "kind of new" for OAuth2 (from an explicit specification perspective).

Fair enough. We do provide more specific guidance on the use of audience
for API, the language you quote later on being an example of that.

 Also, there is the concept of 'azp' from the id_token which amounts to
> "who's allowed to present this token" which might be interesting from the
> case where one entity obtains the token, and gives it to another entity to
> present. Not sure if we want to include this concept or not.

We embedded that in the client_id claim. I originally had azp but got
strong pushback, given the debacle it caused in the past (see
https://bitbucket.org/openid/connect/issues/1009/contradictory-statements-about-id-token?fbclid=IwAR2iPZcEStXGXB-9SW0889Ky1cpKbK8h1WdjyQX2PKMly4nN6050Na4KfYw
,
https://bitbucket.org/openid/connect/issues/973/core-2-3137-azp-claim-underspecified-and?fbclid=IwAR0IN6JT_jPqukOzsbegJLY2MXl1xnplURjXoxSyhd3kvgfw6Nj6LsPLU5M
).

I think for most implementations this would amount to... define an audience
> that covers all the resource services where the access token can be
> returned and set that as the audience (e.g. urn:x-mydomain:apis). Which is
> perfectly legal but maybe not in the spirit of the spec:) I am receiving
> feedback from developers that binding access tokens narrowly to the
> resource where they will be presented is concerning from a chattiness
> perspective (latency issues) and general load on the deployed AS
> infrastructure.

This is an interesting point. In my experience, the main boundary used to
define a resource is either reflecting an underlying, *actual* resource
that exists independently of the API facade slapped on top of it (say a VM)
or it is the context within a certains et of scopes makes sense (say an API
facading access to a bunch of documents).
Some of that criterion is reflected in the rationale for sigle value
audiences. Do you think it should be made more explicit? Perhaps in a
dedicated section?

On Thu, Apr 4, 2019 at 7:07 AM George Fletcher  wrote:

> Another comment...
>
>aud  REQUIRED - as defined in section 2 of [OpenID.Core 
> ].
>   See
>   Section 3 
> 
>  for indications on how an authorization server should
>   determine the value of aud depending on the request.  [Note: some
>   vendors seem to rely on resource aliases.  If we believe this to
>   be a valuable feature, here's some proposed language: The aud
>   claim MAY include a list of individual resource indicators if they
>   are all aliases referring to the same requested resource known by
>   the authorization server. ]
>
>
>
> I don't think OpenID.Core Section 3 is the correct reference for
> determining the 'aud' value. The issue here is that the 'aud' of the
> id_token is the recipient of the id_token (i.e. the client). However, for
> access_tokens the 'aud' value should be the resource service that will
> receive the access_token. There is no existing guidance for this and we
> should provide such guidance as this is "kind of new" for OAuth2 (from an
> explicit specification perspective).
>
> Also, there is the concept of 'azp' from the id_token which amounts to
> "who's allowed to present this token" which might be interesting from the
> case where one entity obtains the token, and gives it to another entity to
> present. Not sure if we want to include this concept or not.
>
> Finally, I think we may need some best practice around how the concept of
> audience and resource should be managed. For instance...
>
>If the request does not include a resource parameter, the
>authorization server MUST use in the aud claim a default resource
>indicator.  If a scope parameter is present in the request, the
>authorization server SHOULD use it to infer the value of the default
>resource indicator to be used in the aud claim.
>
>
> I think for most implementations this would amount to... define an
> audience that covers all the resource services where the access token can
> be returned and set that as the audience (e.g. urn:x-mydomain:apis). Which
> is perfectly legal but maybe not in the spirit of the spec:) I am receiving
> feedback from developers that binding access tokens narrowly to the
> resource where they will be presented is concerning from a chattiness
> perspective (latency issues) and general load on the deployed AS
> infrastructure.
>
> On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
>
> Dear all,
> I just submitted a draft

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

But before I get in the details, let me make an uber-point.
I am acutely aware of the potential for confusion and abuse in the context
of OAuth and sign in, the article you pointed to quotes my own articles on
the matter extensively. But there are concrete aspects that need to be
considered about what developers are trying to achieve in practice.
OAuth2 is the de facto mechanism to secure API calls nowadays. That
includes scenarios not directly addressed by the spec, such as first party
APIs. People do that for 1st party APIs as well because they can leverage a
well supported mechanism for driving authentication experiences and
outsource authentication to products and services.
Forgetting for a second about the fact that 3rd party APIs can use identity
and authentication levels info as well, let me focus for a second on 1st
party APIs. From the functionality perspective, delivering an app as a web
site or as a native client+API combination doesn't change the business
requirements and the information a backend needs to do its job.
Given that we tell people NOT to use ID tokens for calling APIs: if a
developer chooses to deliver their app as a native client+API instead of a
web site, the only artifact they have available is the access token. So
either we embed the info in the access token, and we do what we can to
prevent abuse and the most likely pitfalls/privacy challenges/etc in the
guidance, or we find a way for 1st party APIs to consume ID tokens (which
is problematic- I discussed this with John and Nat at OSW and the place we
got stuck on was that we can; safely use sender constrain in that
scenario). And to pre-empt comments on userinfo, that's asking for a lot of
extra moving parts- the only outcome will be that people will keep
embedding the info they need in the AT, but will do so in non-interoperable
way, and without the guidance and warnings that would at least contain some
of the damage.

That said, inline.

My concern isn't with reusing the names/types of the claims per se.  But
> more generally that codifying the use of certain authentication-centric
> claims in the context of an access token furthers the potential confusion
> around authentication vs. authorization that has been a nagging problem for
> OAuth (i.e. the https://oauth.net/articles/authentication/ article).

see preamble.

I  understand what you are saying but but personally do not find it
> sufficiently compelling.  But that's just my opinion and not a hill I want
> to die on (at the present time anyway)..

Noted :) does the fact that in some scenarios the AT might be the *only*
artifact a backend will receive change the stance?

 By the time it came up again near the end of the last unconference
> session, I wasn't wanting to prolong things because I was kinda worn out
> for the day and wanting to get to Frankfurt that evening before sunset
> ('cause I like to do stuff like this: https://flic.kr/p/2fiAaPe :) ).

Sorry for having tired you out :) at the time I echoed back what was
suggested (to reflect the original values in the session) precisely to make
sure everyone had a chance to push back, and I got lots of nods (including
from John who was in the first row). I misinterpreted your silence as
assent, given that during that session you did chime in on other matters..
but I was expecting the discussion to keep going on the ML anyway, so it's
all according to plan :)

 FWIW, to me, George's suggestion "assume[ing] that the auth_time value
> should be updated to the latest time at which the user authenticated"
> though some unspecified and in many cases non-existent link between the AT
> and a current user session at the AS is an example of how
> authentication-centric claims in an access token can be confusing.

 I agree it can be confusing, but to me that makes the need to provide
guidance on it more compelling, not less. There are important scenarios
where access decisions are made on the basis of that information, and
implementations WILL find a way to get the info they are interested into.
To me that's all the more reasons to provide guidance on how to do so being
aware of pitfalls and with whatever protections we can put in place, as
opposed to leave developers to their own device.

On Thu, Apr 4, 2019 at 9:32 AM Brian Campbell  wrote:

> A few remarks/responses inline below this time...
>
> On Wed, Apr 3, 2019 at 1:38 PM Vittorio Bertocci  40auth0@dmarc.ietf.org> wrote:
>
>> Thanks guys for the comment, sorry for the delay in addressing them.
>> I am not married to the claim types used in here, so if you think that
>> reusing the ones in the id_token can cause confusion we should expand on
>> the specific ways in which you think might go south.
>>
>
> My concern isn't with reusing the names/types of the claims per se.  But
> more generally that codifying the use of certain authentication-centric
> claims in the context of an access token furthers the potential confusion
> around authentication vs. authorization that

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

2019-04-04 Thread Schanzenbach, Martin

I agree. Maybe RFC 7519 is actually as good as it gets wrt claim specifications?
At least for OAuth. Use case specific profiles can/must then use their own 
definitions (see OIDC) for (JWT) ATs.
I mean, at least for OIDC, an AT which is the result of a client credential 
grant isn't even a thing which really simplifies the specification of a JWT AT 
in OIDC.

So maybe just reference / rely on RFC 7519 for the basic claims and clarify 
usage of this JWT using the typ?

> On 4. Apr 2019, at 18:29, Hans Zandbelt  wrote:
> 
> I believe the root problem is that we're trying to unify across tokens that 
> are issued for different use cases (auth vs. authz), different subjects and 
> different audiences. The JWT spec allows us to cover those use cases nicely 
> within its own semantics but the profile specific use case semantics are 
> really different at heart. This problem becomes even more apparent in SPAs 
> that share both the id_token and the access_token across frontend and 
> backend: the RS then needs to flip back and forth between the use cases and 
> their specific semantics.
> 
> It seems were stuck between a rock and a hard place: I don't think there's a 
> way to make things explicit and clear across use cases whilst sticking with 
> JWT semantics only (as clear as the semantics may be in their own RFC7519 
> context). I also don't think there's a way to make things explicit and clear 
> without breaking existing deployments and existing spec text which is as 
> awkward.
> 
> Hans.
> 
> On Thu, Apr 4, 2019 at 5:58 PM Schanzenbach, Martin 
>  wrote:
> I think what needs to be clarified is whether the "sub" claim should denote 
> the caller (=client) or the RO in the case of an JWT AT.
> RFC 7519 only defines "sub" to be the principal which is the subject of all 
> claims in the JWT.
> This means that the AT can contain either claims regarding the client OR the 
> RO, but not both. (I prefer to use RO instead of user as I think this a term 
> better used in OIDC).
> 
> Now, the question is what does an RS need to make an authorisation decision? 
> Claims about the client or claims about the RO?
> Since OIDC already has ID Tokens as JWT which have the RO as "sub", maybe it 
> makes sense to have the client as sub for the AT?
> If the RS needs claims about the RO in order to do authorization decisions, 
> maybe it needs to be presented with an ID Token (which would imply that it is 
> issued with the RS in its aud claim).
> 
> > On 4. Apr 2019, at 17:50, George Fletcher 
> >  wrote:
> >
> > The more I think about this the more I land in the "No" camp.
> >
> > The subject of a token should be the principal of that token. It shouldn't 
> > matter whether that is a machine, a user, or a device. Trying to separate 
> > out "humans" as a special class will just make things more complicated. If 
> > we need a claim to identify the subject is a "human" then why not just add 
> > that. This doesn't break anything and makes it easy for people to detect 
> > this case in those use cases where it's required.
> >
> > Thanks,
> > George
> >
> > On 4/3/19 4:56 PM, Hans Zandbelt wrote:
> >> I will argue that in a way such deployments are already broken e.g. in the 
> >> typical use case of onboarding client accounts in the same 
> >> directory/OU/namespace as user accounts and we don't need to cater for 
> >> that.
> >>
> >> Hans.
> >>
> >> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher  wrote:
> >> I agree that this will break a lot of existing flows... especially those 
> >> using any form of the client_credentials flow. In that sense I'm not 
> >> completely on board yet :)
> >>
> >> On 3/26/19 12:56 PM, Hans Zandbelt wrote:
> >>> great summary! this will hurt quite a few existing m2m deployments but I 
> >>> do like the rigidness of it all: it is very explicit, cannot 
> >>> misinterpreted and thus prevents failure (which is really what Dominick 
> >>> is after); I'm on board
> >>>
> >>> Hans.
> >>>
> >>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci 
> >>>  wrote:
> >>> thank you Steinar and everyone else for the comments on this!
> >>> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, 
> >>> Bertrand recommend using sub only for users. Martin would like to have 
> >>> the sub for app only flows as well. Hans is neutral.
> >>> That does sound like the sub as user has more consensus, tho before 
> >>> changing it I'd wait for the people currently at IETF104 to have more 
> >>> time to comment as well.
> >>> Clarification. If the goal is to be able to apply the logic "if there's a 
> >>> sub, it's a user flow", we have to explicitly disallow (MUST NOT) the use 
> >>> of sub when that's not the case. Are all OK with it?
> >>>
> >>> Dave, the suggestion of having explicit typing for app only vs user only 
> >>> is interesting! For the purpose of putting together an interoperable 
> >>> profile, tho, I would suggest we table it for v1 in the interest of 
> >>> getting to something easy to

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

A few remarks/responses inline below this time...

On Wed, Apr 3, 2019 at 1:38 PM Vittorio Bertocci  wrote:

> Thanks guys for the comment, sorry for the delay in addressing them.
> I am not married to the claim types used in here, so if you think that
> reusing the ones in the id_token can cause confusion we should expand on
> the specific ways in which you think might go south.
>

My concern isn't with reusing the names/types of the claims per se.  But
more generally that codifying the use of certain authentication-centric
claims in the context of an access token furthers the potential confusion
around authentication vs. authorization that has been a nagging problem for
OAuth (i.e. the https://oauth.net/articles/authentication/ article).

However I think it's important that the information on say, whether the
> current token was obtained using MFA or a specific authentication factor is
> something that API developers can legitimately latch to when doing
> authorization decisions. From the perspective of a developer modeling a
> solution, whether functionality is delivered as a route in a postback based
> web app (hence receiving an id_token or derived) or as an API consumed by a
> native app, the business requirement gating access to that functionality
> doesn't change. If the admin managing that resource establishes that access
> should be performed only via MFA, the developer should be equipped to
> enforce that regardless of the stack used to expose functionality (web app,
> API).
> Although it is true that triggering the desired behavior might be achieved
> by the resource setting and contract with the AS, along the lines of what
> David said, it's actually not uncommon for those policies to be assigned on
> the resource AFTER the current session was established and/or the
> corresponding AT was obtained and cached. Furthermore, the requirement
> might be more granular than an AS policy can tolerate (an API might
> requires MFA only for certain routes, hence hard to express in a static
> policy) and triggered in form of challenges. So the situation in which you
> have an AT with the right issuer, audience, etc but was obtained with a
> policy now obsolete/unacceptable to the RP is strong. Requesting to support
> revocation just for this seems overkill, especially given that the scenario
> in which the same logical app is exposed as both web app and native
> client+API, the code consuming those claims is already in place. It just
> makes intuitive sense for developers.
> In summary, one can take steps to push as much of the MFA requirements to
> the AS settings for a particular request, but ultimately the desire of the
> API developer to enforce that it actually happened is a requirement I
> encountered often in practice. Anything providing extra context to refine
> decisions about it (like auth_time, which might inform decisions about
> whether to accept an MFA check occurred N minutes ago or refuse access).
>

I understand what you are saying but but personally do not find it
sufficiently compelling.  But that's just my opinion and not a hill I want
to die on (at the present time anyway).

> I thought that reusing the existing names for the same concepts just made
> sense (dev existing skills, existing codebases, etc etc) and especially in
> the case in which the values are exactly the same, and the idea seemed to
> receive good support during OSW.
>

Our recollection of OSW differs somewhat. As I recall there was support for
pointing to identity claims from OIDC for additional end-user info. But
there was some grumbling (from John and myself at least) at first mention
of acr/amr and auth_time. By the time it came up again near the end of the
last unconference session, I wasn't wanting to prolong things because I was
kinda worn out for the day and wanting to get to Frankfurt that evening
before sunset ('cause I like to do stuff like this:
https://flic.kr/p/2fiAaPe :) ).

> But I am completely open to change it of course, especially for cases like
> the one identified by George.
>

FWIW, to me, George's suggestion "assume[ing] that the auth_time value
should be updated to the latest time at which the user authenticated"
though some unspecified and in many cases non-existent link between the AT
and a current user session at the AS is an example of how
authentication-centric claims in an access token can be confusing.

> WDYT?
>
> On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
>> +1 to David's question here. I'd like to see justifying use cases (beyond
>> just the fact that some people are already doing it) for auth_time, acr,
>> and amr to be available in OAuth JWT access tokens. Those claims are
>> defined for, and in the context of, an ID Token and I fear that codifying
>> their use in an access token will lead to misuse and/or confusion.
>>
>> On Mon, Apr 1, 2019 at 1:03 PM David Waite 
>> wrote:
>>
>>> Do we know if there is a justifying use

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

I believe the root problem is that we're trying to unify across tokens that
are issued for different use cases (auth vs. authz), different subjects and
different audiences. The JWT spec allows us to cover those use cases nicely
within its own semantics but the profile specific use case semantics are
really different at heart. This problem becomes even more apparent in SPAs
that share both the id_token and the access_token across frontend and
backend: the RS then needs to flip back and forth between the use cases and
their specific semantics.

It seems were stuck between a rock and a hard place: I don't think there's
a way to make things explicit and clear across use cases whilst sticking
with JWT semantics only (as clear as the semantics may be in their own
RFC7519 context). I also don't think there's a way to make things explicit
and clear without breaking existing deployments and existing spec text
which is as awkward.

Hans.

On Thu, Apr 4, 2019 at 5:58 PM Schanzenbach, Martin <
martin.schanzenb...@aisec.fraunhofer.de> wrote:

> I think what needs to be clarified is whether the "sub" claim should
> denote the caller (=client) or the RO in the case of an JWT AT.
> RFC 7519 only defines "sub" to be the principal which is the subject of
> all claims in the JWT.
> This means that the AT can contain either claims regarding the client OR
> the RO, but not both. (I prefer to use RO instead of user as I think this a
> term better used in OIDC).
>
> Now, the question is what does an RS need to make an authorisation
> decision? Claims about the client or claims about the RO?
> Since OIDC already has ID Tokens as JWT which have the RO as "sub", maybe
> it makes sense to have the client as sub for the AT?
> If the RS needs claims about the RO in order to do authorization
> decisions, maybe it needs to be presented with an ID Token (which would
> imply that it is issued with the RS in its aud claim).
>
> > On 4. Apr 2019, at 17:50, George Fletcher  40aol@dmarc.ietf.org> wrote:
> >
> > The more I think about this the more I land in the "No" camp.
> >
> > The subject of a token should be the principal of that token. It
> shouldn't matter whether that is a machine, a user, or a device. Trying to
> separate out "humans" as a special class will just make things more
> complicated. If we need a claim to identify the subject is a "human" then
> why not just add that. This doesn't break anything and makes it easy for
> people to detect this case in those use cases where it's required.
> >
> > Thanks,
> > George
> >
> > On 4/3/19 4:56 PM, Hans Zandbelt wrote:
> >> I will argue that in a way such deployments are already broken e.g. in
> the typical use case of onboarding client accounts in the same
> directory/OU/namespace as user accounts and we don't need to cater for that.
> >>
> >> Hans.
> >>
> >> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher 
> wrote:
> >> I agree that this will break a lot of existing flows... especially
> those using any form of the client_credentials flow. In that sense I'm not
> completely on board yet :)
> >>
> >> On 3/26/19 12:56 PM, Hans Zandbelt wrote:
> >>> great summary! this will hurt quite a few existing m2m deployments but
> I do like the rigidness of it all: it is very explicit, cannot
> misinterpreted and thus prevents failure (which is really what Dominick is
> after); I'm on board
> >>>
> >>> Hans.
> >>>
> >>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci  40auth0@dmarc.ietf.org> wrote:
> >>> thank you Steinar and everyone else for the comments on this!
> >>> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov,
> Bertrand recommend using sub only for users. Martin would like to have the
> sub for app only flows as well. Hans is neutral.
> >>> That does sound like the sub as user has more consensus, tho before
> changing it I'd wait for the people currently at IETF104 to have more time
> to comment as well.
> >>> Clarification. If the goal is to be able to apply the logic "if
> there's a sub, it's a user flow", we have to explicitly disallow (MUST NOT)
> the use of sub when that's not the case. Are all OK with it?
> >>>
> >>> Dave, the suggestion of having explicit typing for app only vs user
> only is interesting! For the purpose of putting together an interoperable
> profile, tho, I would suggest we table it for v1 in the interest of getting
> to something easy to adopt (hence with small delta vs existing
> implementations) faster.
> >>>
> >>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem  wrote:
> >>> Hi Vittorio, we  (the national federation-gateway for the health
> services in norway - "HelseID")  think his is a really valuable initiative!
> >>> We also agree with Dominick concerning definition of the "sub" claim.
> >>>
> >>> Steinar
> >>>
> >>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <
> dba...@leastprivilege.com>:
> >>> From an access token consumer (aka API) developer point of view, I
> prefer this logic
> >>>
> >>> "If sub is present -

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

2019-04-04 Thread Schanzenbach, Martin

I think what needs to be clarified is whether the "sub" claim should denote the 
caller (=client) or the RO in the case of an JWT AT.
RFC 7519 only defines "sub" to be the principal which is the subject of all 
claims in the JWT.
This means that the AT can contain either claims regarding the client OR the 
RO, but not both. (I prefer to use RO instead of user as I think this a term 
better used in OIDC).

Now, the question is what does an RS need to make an authorisation decision? 
Claims about the client or claims about the RO?
Since OIDC already has ID Tokens as JWT which have the RO as "sub", maybe it 
makes sense to have the client as sub for the AT?
If the RS needs claims about the RO in order to do authorization decisions, 
maybe it needs to be presented with an ID Token (which would imply that it is 
issued with the RS in its aud claim).

> On 4. Apr 2019, at 17:50, George Fletcher  
> wrote:
> 
> The more I think about this the more I land in the "No" camp.
> 
> The subject of a token should be the principal of that token. It shouldn't 
> matter whether that is a machine, a user, or a device. Trying to separate out 
> "humans" as a special class will just make things more complicated. If we 
> need a claim to identify the subject is a "human" then why not just add that. 
> This doesn't break anything and makes it easy for people to detect this case 
> in those use cases where it's required.
> 
> Thanks,
> George
> 
> On 4/3/19 4:56 PM, Hans Zandbelt wrote:
>> I will argue that in a way such deployments are already broken e.g. in the 
>> typical use case of onboarding client accounts in the same 
>> directory/OU/namespace as user accounts and we don't need to cater for that.
>> 
>> Hans.
>> 
>> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher  wrote:
>> I agree that this will break a lot of existing flows... especially those 
>> using any form of the client_credentials flow. In that sense I'm not 
>> completely on board yet :)
>> 
>> On 3/26/19 12:56 PM, Hans Zandbelt wrote:
>>> great summary! this will hurt quite a few existing m2m deployments but I do 
>>> like the rigidness of it all: it is very explicit, cannot misinterpreted 
>>> and thus prevents failure (which is really what Dominick is after); I'm on 
>>> board
>>> 
>>> Hans.
>>> 
>>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci 
>>>  wrote:
>>> thank you Steinar and everyone else for the comments on this!
>>> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, 
>>> Bertrand recommend using sub only for users. Martin would like to have the 
>>> sub for app only flows as well. Hans is neutral.
>>> That does sound like the sub as user has more consensus, tho before 
>>> changing it I'd wait for the people currently at IETF104 to have more time 
>>> to comment as well.
>>> Clarification. If the goal is to be able to apply the logic "if there's a 
>>> sub, it's a user flow", we have to explicitly disallow (MUST NOT) the use 
>>> of sub when that's not the case. Are all OK with it?
>>> 
>>> Dave, the suggestion of having explicit typing for app only vs user only is 
>>> interesting! For the purpose of putting together an interoperable profile, 
>>> tho, I would suggest we table it for v1 in the interest of getting to 
>>> something easy to adopt (hence with small delta vs existing 
>>> implementations) faster.
>>> 
>>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem  wrote:
>>> Hi Vittorio, we  (the national federation-gateway for the health services 
>>> in norway - "HelseID")  think his is a really valuable initiative!
>>> We also agree with Dominick concerning definition of the "sub" claim.
>>> 
>>> Steinar
>>> 
>>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier 
>>> :
>>> From an access token consumer (aka API) developer point of view, I prefer 
>>> this logic
>>> 
>>> "If sub is present - client acts on behalf of a user, if not - not."
>>> 
>>> Anything more complicated has a potential of going wrong.
>>> 
>>> 
>>> On 26. March 2019 at 01:34:53, Nov Matake (mat...@gmail.com) wrote:
>>> 
 Hi Vittorio,
 
 Yeah, I’m concerning user & client ids collision.
 I haven’t seen such implementations, but user-select username as sub, or 
 incremental integer as sub & client_id will be easily collide.
 
 If you can enforce collision resistant IDs between user & client 
 instances, it’ll works fine. I feel its overkill though.
 
 Sent from my iPhone
 
 On Mar 26, 2019, at 8:51, Vittorio Bertocci  wrote:
 
> Hey Nov, Dominick, Hans-
> thanks for the comments. That was an area I was expecting to cause more 
> discussion, and I am glad we are having this opportunity to clarify.
> The current language in the draft traces the etymology of sub to OpenID 
> Connect core, hence Dominick observation is on point. However in the 
> description I express something in line with 7519, which was in fact my 
> intent.
> 
> The idea was to provide an identifier

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00


The more I think about this the more I land in the "No" camp.

The subject of a token should be the principal of that token. It 
shouldn't matter whether that is a machine, a user, or a device. Trying 
to separate out "humans" as a special class will just make things more 
complicated. If we need a claim to identify the subject is a "human" 
then why not just add that. This doesn't break anything and makes it 
easy for people to detect this case in those use cases where it's required.


Thanks,
George

On 4/3/19 4:56 PM, Hans Zandbelt wrote:
I will argue that in a way such deployments are already broken e.g. in 
the typical use case of onboarding client accounts in the same 
directory/OU/namespace as user accounts and we don't need to cater for 
that.


Hans.

On Wed, Apr 3, 2019 at 10:48 PM George Fletcher > wrote:


I agree that this will break a lot of existing flows... especially
those using any form of the client_credentials flow. In that sense
I'm not completely on board yet :)

On 3/26/19 12:56 PM, Hans Zandbelt wrote:

great summary! this will hurt quite a few existing m2m
deployments but I do like the rigidness of it all: it is very
explicit, cannot misinterpreted and thus prevents failure (which
is really what Dominick is after); I'm on board

Hans.

On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci
mailto:40auth0@dmarc.ietf.org>> wrote:

thank you Steinar and everyone else for the comments on this!
To summarize the situation so far: Dominick, Steinar, Rob,
David, Nov, Bertrand recommend using sub only for users.
Martin would like to have the sub for app only flows as well.
Hans is neutral.
That does sound like the sub as user has more consensus, tho
before changing it I'd wait for the people currently at
IETF104 to have more time to comment as well.
Clarification. If the goal is to be able to apply the logic
"if there's a sub, it's a user flow", we have to explicitly
disallow (MUST NOT) the use of sub when that's not the case.
Are all OK with it?

Dave, the suggestion of having explicit typing for app only
vs user only is interesting! For the purpose of putting
together an interoperable profile, tho, I would suggest we
table it for v1 in the interest of getting to something easy
to adopt (hence with small delta vs existing implementations)
faster.

On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem
mailto:stei...@udelt.no>> wrote:

Hi Vittorio, we  (the national federation-gateway for the
health services in norway - "HelseID")  think his is a
really valuable initiative!
We also agree with Dominick concerning definition of the
"sub" claim.

Steinar

tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier
mailto:dba...@leastprivilege.com>>:

From an access token consumer (aka API) developer
point of view, I prefer this logic

"If sub is present - client acts on behalf of a user,
if not - not."

Anything more complicated has a potential of going wrong.


On 26. March 2019 at 01:34:53, Nov Matake
(mat...@gmail.com ) wrote:


Hi Vittorio,

Yeah, I’m concerning user & client ids collision.
I haven’t seen such implementations, but user-select
username as sub, or incremental integer as sub &
client_id will be easily collide.

If you can enforce collision resistant IDs between
user & client instances, it’ll works fine. I feel
its overkill though.

Sent from my iPhone

On Mar 26, 2019, at 8:51, Vittorio Bertocci
mailto:vitto...@auth0.com>> wrote:


Hey Nov, Dominick, Hans-
thanks for the comments. That was an area I was
expecting to cause more discussion, and I am glad
we are having this opportunity to clarify.
The current language in the draft traces the
etymology of sub to OpenID Connect core, hence
Dominick observation is on point. However in the
description I express something in line with 7519,
which was in fact my intent.

The idea was to provide an identifier of the
calling subject that is guaranteed to be present in
all cases- this would allow an SDK developer to use
the same code for things like lookups and
membership checks regardless of the nature of the
caller (user in a delegated case, app in app-only
grants). The

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

I'm not sure I understand what you mean but this document would reference
the RFC 7519 claims and, if needed, futher profile their usage for access
tokens.

On Thu, Apr 4, 2019 at 9:39 AM Hans Zandbelt 
wrote:

> agreed but it (i.e. "sub") also brings us back to where we started
>
> Hans.
>
> On Thu, Apr 4, 2019 at 5:27 PM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
>> The same is true for most of the other main claims too - iss, exp, aud,
>> sub, iat, etc.. They are defined in RFC 7519 not OIDC.
>>
>> On Thu, Apr 4, 2019 at 9:21 AM Brian Campbell 
>> wrote:
>>
>>> Yeah, OpenID.Core isn't the right reference for `aud`.
>>> https://tools.ietf.org/html/rfc7519#section-4.1.3 is the definition of
>>> `aud` which should be the reference and this document can provide
>>> additional specifics for the given application.
>>>
>>> On Thu, Apr 4, 2019 at 8:07 AM George Fletcher >> 40aol@dmarc.ietf.org> wrote:
>>>
 Another comment...

aud  REQUIRED - as defined in section 2 of [OpenID.Core 
 ].
   See
   Section 3 

  for indications on how an authorization server should
   determine the value of aud depending on the request.  [Note: some
   vendors seem to rely on resource aliases.  If we believe this to
   be a valuable feature, here's some proposed language: The aud
   claim MAY include a list of individual resource indicators if they
   are all aliases referring to the same requested resource known by
   the authorization server. ]

 I don't think OpenID.Core Section 3 is the correct reference for
 determining the 'aud' value. The issue here is that the 'aud' of the
 id_token is the recipient of the id_token (i.e. the client). However, for
 access_tokens the 'aud' value should be the resource service that will
 receive the access_token. There is no existing guidance for this and we
 should provide such guidance as this is "kind of new" for OAuth2 (from an
 explicit specification perspective).

 Also, there is the concept of 'azp' from the id_token which amounts to
 "who's allowed to present this token" which might be interesting from the
 case where one entity obtains the token, and gives it to another entity to
 present. Not sure if we want to include this concept or not.

 Finally, I think we may need some best practice around how the concept
 of audience and resource should be managed. For instance...

If the request does not include a resource parameter, the
authorization server MUST use in the aud claim a default resource
indicator.  If a scope parameter is present in the request, the
authorization server SHOULD use it to infer the value of the default
resource indicator to be used in the aud claim.

 I think for most implementations this would amount to... define an
 audience that covers all the resource services where the access token can
 be returned and set that as the audience (e.g. urn:x-mydomain:apis). Which
 is perfectly legal but maybe not in the spirit of the spec:) I am receiving
 feedback from developers that binding access tokens narrowly to the
 resource where they will be presented is concerning from a chattiness
 perspective (latency issues) and general load on the deployed AS
 infrastructure.

 On 3/24/19 7:29 PM, Vittorio Bertocci wrote:

 Dear all,
 I just submitted a draft describing a JWT profile for OAuth 2.0 access
 tokens. You can find it in
 https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/
 .
 I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting
 remotely). I look forward for your comments!

 Here's just a bit of backstory, in case you are interested in how this
 doc came to be. The trajectory it followed is somewhat unusual.

- Despite OAuth2 not requiring any specific format for ATs, through
the years I have come across multiple proprietary solution using JWT for
their access token. The intent and scenarios addressed by those 
 solutions
are mostly the same across vendors, but the syntax and interpretations 
 in
the implementations are different enough to prevent developers from 
 reusing
code and skills when moving from product to product.
- I asked several individuals from key products and services to
share with me concrete examples of their JWT access tokens (THANK YOU
Dominick Baier (IdentityServer), Brian Campbell (PingIdentity),
Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and
explanations!).
I studied and compared all those

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00


:)

The more I think about 'sub' the more I don't think is should mean 
"user". What about an IoT device? To me it feels like 'sub' should be 
what 7519 states, the subject or principal of the token. In some cases, 
that is quite legitimately the "client" or "machine". Changing that 
semantic seems bad. If a developer needs to know whether this JWT is 
about a "human" or not, that's something else entirely and could have 
it's own claim.


On 4/4/19 11:38 AM, Hans Zandbelt wrote:

agreed but it (i.e. "sub") also brings us back to where we started

Hans.

On Thu, Apr 4, 2019 at 5:27 PM Brian Campbell 
> wrote:


The same is true for most of the other main claims too - iss, exp,
aud, sub, iat, etc.. They are defined in RFC 7519 not OIDC.

On Thu, Apr 4, 2019 at 9:21 AM Brian Campbell
mailto:bcampb...@pingidentity.com>>
wrote:

Yeah, OpenID.Core isn't the right reference for `aud`.
https://tools.ietf.org/html/rfc7519#section-4.1.3 is the
definition of `aud` which should be the reference and this
document can provide additional specifics for the given
application.

On Thu, Apr 4, 2019 at 8:07 AM George Fletcher
mailto:40aol@dmarc.ietf.org>> wrote:

Another comment...

aud  REQUIRED - as defined in section 2 of [OpenID.Core  
].
  See
   Section 3  

  for indications on how an authorization server should
   determine the value of aud depending on the request.  [Note: 
some
   vendors seem to rely on resource aliases.  If we believe 
this to
   be a valuable feature, here's some proposed language: The aud
   claim MAY include a list of individual resource indicators 
if they
   are all aliases referring to the same requested resource 
known by
   the authorization server. ]



I don't think OpenID.Core Section 3 is the correct
reference for determining the 'aud' value. The issue here
is that the 'aud' of the id_token is the recipient of the
id_token (i.e. the client). However, for access_tokens the
'aud' value should be the resource service that will
receive the access_token. There is no existing guidance
for this and we should provide such guidance as this is
"kind of new" for OAuth2 (from an explicit specification
perspective).

Also, there is the concept of 'azp' from the id_token
which amounts to "who's allowed to present this token"
which might be interesting from the case where one entity
obtains the token, and gives it to another entity to
present. Not sure if we want to include this concept or not.

Finally, I think we may need some best practice around how
the concept of audience and resource should be managed.
For instance...

If the request does not include a resource parameter, the
authorization server MUST use in the aud claim a default 
resource
indicator.  If a scope parameter is present in the request, the
authorization server SHOULD use it to infer the value of the 
default
resource indicator to be used in the aud claim.

I think for most implementations this would amount to...
define an audience that covers all the resource services
where the access token can be returned and set that as the
audience (e.g. urn:x-mydomain:apis). Which is perfectly
legal but maybe not in the spirit of the spec:) I am
receiving feedback from developers that binding access
tokens narrowly to the resource where they will be
presented is concerning from a chattiness perspective
(latency issues) and general load on the deployed AS
infrastructure.

On 3/24/19 7:29 PM, Vittorio Bertocci wrote:

Dear all,
I just submitted a draft describing a JWT profile for
OAuth 2.0 access tokens. You can find it in

https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll
be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are
interested in how this doc came to be. The trajectory it
followed is somewhat unusual.

  * Despite OAuth2 not requiring any specific format for
ATs, through the years I have come across multiple
proprietary

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

agreed but it (i.e. "sub") also brings us back to where we started

Hans.

On Thu, Apr 4, 2019 at 5:27 PM Brian Campbell  wrote:

> The same is true for most of the other main claims too - iss, exp, aud,
> sub, iat, etc.. They are defined in RFC 7519 not OIDC.
>
> On Thu, Apr 4, 2019 at 9:21 AM Brian Campbell 
> wrote:
>
>> Yeah, OpenID.Core isn't the right reference for `aud`.
>> https://tools.ietf.org/html/rfc7519#section-4.1.3 is the definition of
>> `aud` which should be the reference and this document can provide
>> additional specifics for the given application.
>>
>> On Thu, Apr 4, 2019 at 8:07 AM George Fletcher > 40aol@dmarc.ietf.org> wrote:
>>
>>> Another comment...
>>>
>>>aud  REQUIRED - as defined in section 2 of [OpenID.Core 
>>> ].
>>>   See
>>>   Section 3 
>>> 
>>>  for indications on how an authorization server should
>>>   determine the value of aud depending on the request.  [Note: some
>>>   vendors seem to rely on resource aliases.  If we believe this to
>>>   be a valuable feature, here's some proposed language: The aud
>>>   claim MAY include a list of individual resource indicators if they
>>>   are all aliases referring to the same requested resource known by
>>>   the authorization server. ]
>>>
>>>
>>>
>>> I don't think OpenID.Core Section 3 is the correct reference for
>>> determining the 'aud' value. The issue here is that the 'aud' of the
>>> id_token is the recipient of the id_token (i.e. the client). However, for
>>> access_tokens the 'aud' value should be the resource service that will
>>> receive the access_token. There is no existing guidance for this and we
>>> should provide such guidance as this is "kind of new" for OAuth2 (from an
>>> explicit specification perspective).
>>>
>>> Also, there is the concept of 'azp' from the id_token which amounts to
>>> "who's allowed to present this token" which might be interesting from the
>>> case where one entity obtains the token, and gives it to another entity to
>>> present. Not sure if we want to include this concept or not.
>>>
>>> Finally, I think we may need some best practice around how the concept
>>> of audience and resource should be managed. For instance...
>>>
>>>If the request does not include a resource parameter, the
>>>authorization server MUST use in the aud claim a default resource
>>>indicator.  If a scope parameter is present in the request, the
>>>authorization server SHOULD use it to infer the value of the default
>>>resource indicator to be used in the aud claim.
>>>
>>>
>>> I think for most implementations this would amount to... define an
>>> audience that covers all the resource services where the access token can
>>> be returned and set that as the audience (e.g. urn:x-mydomain:apis). Which
>>> is perfectly legal but maybe not in the spirit of the spec:) I am receiving
>>> feedback from developers that binding access tokens narrowly to the
>>> resource where they will be presented is concerning from a chattiness
>>> perspective (latency issues) and general load on the deployed AS
>>> infrastructure.
>>>
>>> On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
>>>
>>> Dear all,
>>> I just submitted a draft describing a JWT profile for OAuth 2.0 access
>>> tokens. You can find it in
>>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting
>>> remotely). I look forward for your comments!
>>>
>>> Here's just a bit of backstory, in case you are interested in how this
>>> doc came to be. The trajectory it followed is somewhat unusual.
>>>
>>>- Despite OAuth2 not requiring any specific format for ATs, through
>>>the years I have come across multiple proprietary solution using JWT for
>>>their access token. The intent and scenarios addressed by those solutions
>>>are mostly the same across vendors, but the syntax and interpretations in
>>>the implementations are different enough to prevent developers from 
>>> reusing
>>>code and skills when moving from product to product.
>>>- I asked several individuals from key products and services to
>>>share with me concrete examples of their JWT access tokens (THANK YOU
>>>Dominick Baier (IdentityServer), Brian Campbell (PingIdentity),
>>>Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and
>>>explanations!).
>>>I studied and compared all those instances, identifying
>>>commonalities and differences.
>>>- I put together a presentation summarizing my findings and
>>>suggesting a rough interoperable profile (slides:
>>>
>>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx
>>>
>>>

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

The same is true for most of the other main claims too - iss, exp, aud,
sub, iat, etc.. They are defined in RFC 7519 not OIDC.

On Thu, Apr 4, 2019 at 9:21 AM Brian Campbell 
wrote:

> Yeah, OpenID.Core isn't the right reference for `aud`.
> https://tools.ietf.org/html/rfc7519#section-4.1.3 is the definition of
> `aud` which should be the reference and this document can provide
> additional specifics for the given application.
>
> On Thu, Apr 4, 2019 at 8:07 AM George Fletcher  40aol@dmarc.ietf.org> wrote:
>
>> Another comment...
>>
>>aud  REQUIRED - as defined in section 2 of [OpenID.Core 
>> ].
>>   See
>>   Section 3 
>> 
>>  for indications on how an authorization server should
>>   determine the value of aud depending on the request.  [Note: some
>>   vendors seem to rely on resource aliases.  If we believe this to
>>   be a valuable feature, here's some proposed language: The aud
>>   claim MAY include a list of individual resource indicators if they
>>   are all aliases referring to the same requested resource known by
>>   the authorization server. ]
>>
>>
>>
>> I don't think OpenID.Core Section 3 is the correct reference for
>> determining the 'aud' value. The issue here is that the 'aud' of the
>> id_token is the recipient of the id_token (i.e. the client). However, for
>> access_tokens the 'aud' value should be the resource service that will
>> receive the access_token. There is no existing guidance for this and we
>> should provide such guidance as this is "kind of new" for OAuth2 (from an
>> explicit specification perspective).
>>
>> Also, there is the concept of 'azp' from the id_token which amounts to
>> "who's allowed to present this token" which might be interesting from the
>> case where one entity obtains the token, and gives it to another entity to
>> present. Not sure if we want to include this concept or not.
>>
>> Finally, I think we may need some best practice around how the concept of
>> audience and resource should be managed. For instance...
>>
>>If the request does not include a resource parameter, the
>>authorization server MUST use in the aud claim a default resource
>>indicator.  If a scope parameter is present in the request, the
>>authorization server SHOULD use it to infer the value of the default
>>resource indicator to be used in the aud claim.
>>
>>
>> I think for most implementations this would amount to... define an
>> audience that covers all the resource services where the access token can
>> be returned and set that as the audience (e.g. urn:x-mydomain:apis). Which
>> is perfectly legal but maybe not in the spirit of the spec:) I am receiving
>> feedback from developers that binding access tokens narrowly to the
>> resource where they will be presented is concerning from a chattiness
>> perspective (latency issues) and general load on the deployed AS
>> infrastructure.
>>
>> On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
>>
>> Dear all,
>> I just submitted a draft describing a JWT profile for OAuth 2.0 access
>> tokens. You can find it in
>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting
>> remotely). I look forward for your comments!
>>
>> Here's just a bit of backstory, in case you are interested in how this
>> doc came to be. The trajectory it followed is somewhat unusual.
>>
>>- Despite OAuth2 not requiring any specific format for ATs, through
>>the years I have come across multiple proprietary solution using JWT for
>>their access token. The intent and scenarios addressed by those solutions
>>are mostly the same across vendors, but the syntax and interpretations in
>>the implementations are different enough to prevent developers from 
>> reusing
>>code and skills when moving from product to product.
>>- I asked several individuals from key products and services to share
>>with me concrete examples of their JWT access tokens (THANK YOU Dominick
>>Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel
>>Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and 
>> explanations!).
>>
>>I studied and compared all those instances, identifying commonalities
>>and differences.
>>- I put together a presentation summarizing my findings and
>>suggesting a rough interoperable profile (slides:
>>
>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx
>>
>> 
>>) - got early feedback from Filip Skokan on it. Thx Filip!
>>- The presentation was followed up by 1.5 hours of unconference
>>discussion, which was incredibly valuable to get

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

Yeah, OpenID.Core isn't the right reference for `aud`.
https://tools.ietf.org/html/rfc7519#section-4.1.3 is the definition of
`aud` which should be the reference and this document can provide
additional specifics for the given application.

On Thu, Apr 4, 2019 at 8:07 AM George Fletcher  wrote:

> Another comment...
>
>aud  REQUIRED - as defined in section 2 of [OpenID.Core 
> ].
>   See
>   Section 3 
> 
>  for indications on how an authorization server should
>   determine the value of aud depending on the request.  [Note: some
>   vendors seem to rely on resource aliases.  If we believe this to
>   be a valuable feature, here's some proposed language: The aud
>   claim MAY include a list of individual resource indicators if they
>   are all aliases referring to the same requested resource known by
>   the authorization server. ]
>
>
>
> I don't think OpenID.Core Section 3 is the correct reference for
> determining the 'aud' value. The issue here is that the 'aud' of the
> id_token is the recipient of the id_token (i.e. the client). However, for
> access_tokens the 'aud' value should be the resource service that will
> receive the access_token. There is no existing guidance for this and we
> should provide such guidance as this is "kind of new" for OAuth2 (from an
> explicit specification perspective).
>
> Also, there is the concept of 'azp' from the id_token which amounts to
> "who's allowed to present this token" which might be interesting from the
> case where one entity obtains the token, and gives it to another entity to
> present. Not sure if we want to include this concept or not.
>
> Finally, I think we may need some best practice around how the concept of
> audience and resource should be managed. For instance...
>
>If the request does not include a resource parameter, the
>authorization server MUST use in the aud claim a default resource
>indicator.  If a scope parameter is present in the request, the
>authorization server SHOULD use it to infer the value of the default
>resource indicator to be used in the aud claim.
>
>
> I think for most implementations this would amount to... define an
> audience that covers all the resource services where the access token can
> be returned and set that as the audience (e.g. urn:x-mydomain:apis). Which
> is perfectly legal but maybe not in the spirit of the spec:) I am receiving
> feedback from developers that binding access tokens narrowly to the
> resource where they will be presented is concerning from a chattiness
> perspective (latency issues) and general load on the deployed AS
> infrastructure.
>
> On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
>
> Dear all,
> I just submitted a draft describing a JWT profile for OAuth 2.0 access
> tokens. You can find it in
> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting
> remotely). I look forward for your comments!
>
> Here's just a bit of backstory, in case you are interested in how this doc
> came to be. The trajectory it followed is somewhat unusual.
>
>- Despite OAuth2 not requiring any specific format for ATs, through
>the years I have come across multiple proprietary solution using JWT for
>their access token. The intent and scenarios addressed by those solutions
>are mostly the same across vendors, but the syntax and interpretations in
>the implementations are different enough to prevent developers from reusing
>code and skills when moving from product to product.
>- I asked several individuals from key products and services to share
>with me concrete examples of their JWT access tokens (THANK YOU Dominick
>Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian
>(Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
>I studied and compared all those instances, identifying commonalities
>and differences.
>- I put together a presentation summarizing my findings and suggesting
>a rough interoperable profile (slides:
>
> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx
>
> 
>) - got early feedback from Filip Skokan on it. Thx Filip!
>- The presentation was followed up by 1.5 hours of unconference
>discussion, which was incredibly valuable to get tight-loop feedback and
>incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov,
>Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there
>and contributed generously to the discussion. Thank you!!!
>Note: if you were at OSW2019, participated in the discussion and
>

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00