Hi,

I wonder the rationale for apparenty uaa-specific [0] user-related fields
in the access token (username, email [1]) while they are now returned in a
standard maneer in the openidconnect id token.

Is it something that would change in the future ([2] seemed similar
decoupling) ? Or is it a standard practice that avoids clients to request
the idtoken to get access to basic user identity ?

Thanks in advance,

Guillaume.

ps: please let me know if such questions are better suited for a GH issue
on the UAA repo.

[0]
https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-Tokens.md#getting-started

Some of these fields are described in the JSON web tokens specification.

However, the vendor may add additional fields, or attributes, to the token
itself.

[1]
https://github.com/cloudfoundry/uaa/blob/9b5c13d793ebfe358e26559cedc6b528a557b43f/server/src/main/java/org/cloudfoundry/identity/uaa/oauth/UaaTokenServices.java#L493-L497
[2] https://www.pivotaltracker.com/story/show/102090344

Guillaume.

The access token used to double down as an identity token before OpenID
Connect was standardized, now that we have implemented id_token, we don't
really need it. but removing it would cause an backwards incompatible
change.


Filip


On Thu, Mar 31, 2016 at 6:50 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

I wonder the rationale for apparenty uaa-specific [0] user-related fields
in the access token (username, email [1]) while they are now returned in a
standard maneer in the openidconnect id token.

Is it something that would change in the future ([2] seemed similar
decoupling) ? Or is it a standard practice that avoids clients to request
the idtoken to get access to basic user identity ?

Thanks in advance,

Guillaume.

ps: please let me know if such questions are better suited for a GH issue
on the UAA repo.

[0]
https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-Tokens.md#getting-started

Some of these fields are described in the JSON web tokens

specification. However, the vendor may add additional fields, or
attributes, to the token itself.

[1]
https://github.com/cloudfoundry/uaa/blob/9b5c13d793ebfe358e26559cedc6b528a557b43f/server/src/main/java/org/cloudfoundry/identity/uaa/oauth/UaaTokenServices.java#L493-L497
[2] https://www.pivotaltracker.com/story/show/102090344

Guillaume.

Thanks Filip for your answer. Wouldn't it make sense to progressively
change this behavior, possibly controlled by a configuration option to give
clients time to handle this incompatible change?

Scanning quickly through the code I suspect the username and email fields
are systematically returned in the access token, regardless of the presence
of the openid scope (I still have to double check by actually testing it),
therefore disclosing some user identity without his/her consent.

Guillaume.

On Thu, Mar 31, 2016 at 3:03 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

The access token used to double down as an identity token before OpenID
Connect was standardized, now that we have implemented id_token, we don't
really need it. but removing it would cause an backwards incompatible
change.


Filip


On Thu, Mar 31, 2016 at 6:50 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

I wonder the rationale for apparenty uaa-specific [0] user-related
fields in the access token (username, email [1]) while they are now
returned in a standard maneer in the openidconnect id token.

Is it something that would change in the future ([2] seemed similar
decoupling) ? Or is it a standard practice that avoids clients to request
the idtoken to get access to basic user identity ?

Thanks in advance,

Guillaume.

ps: please let me know if such questions are better suited for a GH
issue on the UAA repo.

[0]
https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-Tokens.md#getting-started

Some of these fields are described in the JSON web tokens

specification. However, the vendor may add additional fields, or
attributes, to the token itself.

[1]
https://github.com/cloudfoundry/uaa/blob/9b5c13d793ebfe358e26559cedc6b528a557b43f/server/src/main/java/org/cloudfoundry/identity/uaa/oauth/UaaTokenServices.java#L493-L497
[2] https://www.pivotaltracker.com/story/show/102090344

Guillaume.

yes, they are always returned.

introducing an option sounds like a good idea for the systems that wish to
turn it off, thanks for the idea.

https://www.pivotaltracker.com/story/show/116726159

Filip


On Thu, Mar 31, 2016 at 1:39 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Thanks Filip for your answer. Wouldn't it make sense to progressively
change this behavior, possibly controlled by a configuration option to give
clients time to handle this incompatible change?

Scanning quickly through the code I suspect the username and email fields
are systematically returned in the access token, regardless of the presence
of the openid scope (I still have to double check by actually testing it),
therefore disclosing some user identity without his/her consent.

Guillaume.

On Thu, Mar 31, 2016 at 3:03 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

The access token used to double down as an identity token before OpenID
Connect was standardized, now that we have implemented id_token, we don't
really need it. but removing it would cause an backwards incompatible
change.


Filip


On Thu, Mar 31, 2016 at 6:50 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

I wonder the rationale for apparenty uaa-specific [0] user-related
fields in the access token (username, email [1]) while they are now
returned in a standard maneer in the openidconnect id token.

Is it something that would change in the future ([2] seemed similar
decoupling) ? Or is it a standard practice that avoids clients to request
the idtoken to get access to basic user identity ?

Thanks in advance,

Guillaume.

ps: please let me know if such questions are better suited for a GH
issue on the UAA repo.

[0]
https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-Tokens.md#getting-started

Some of these fields are described in the JSON web tokens

specification. However, the vendor may add additional fields, or
attributes, to the token itself.

[1]
https://github.com/cloudfoundry/uaa/blob/9b5c13d793ebfe358e26559cedc6b528a557b43f/server/src/main/java/org/cloudfoundry/identity/uaa/oauth/UaaTokenServices.java#L493-L497
[2] https://www.pivotaltracker.com/story/show/102090344

Guillaume.

Great, thanks Filip!


Guillaume.

On Thu, Mar 31, 2016 at 9:50 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

yes, they are always returned.

introducing an option sounds like a good idea for the systems that wish
to turn it off, thanks for the idea.

https://www.pivotaltracker.com/story/show/116726159

Filip


On Thu, Mar 31, 2016 at 1:39 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Thanks Filip for your answer. Wouldn't it make sense to progressively
change this behavior, possibly controlled by a configuration option to give
clients time to handle this incompatible change?

Scanning quickly through the code I suspect the username and email
fields are systematically returned in the access token, regardless of the
presence of the openid scope (I still have to double check by actually
testing it), therefore disclosing some user identity without his/her
consent.

Guillaume.

On Thu, Mar 31, 2016 at 3:03 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

The access token used to double down as an identity token before OpenID
Connect was standardized, now that we have implemented id_token, we don't
really need it. but removing it would cause an backwards incompatible
change.


Filip


On Thu, Mar 31, 2016 at 6:50 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

I wonder the rationale for apparenty uaa-specific [0] user-related
fields in the access token (username, email [1]) while they are now
returned in a standard maneer in the openidconnect id token.

Is it something that would change in the future ([2] seemed similar
decoupling) ? Or is it a standard practice that avoids clients to request
the idtoken to get access to basic user identity ?

Thanks in advance,

Guillaume.

ps: please let me know if such questions are better suited for a GH
issue on the UAA repo.

[0]
https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-Tokens.md#getting-started

Some of these fields are described in the JSON web tokens

specification. However, the vendor may add additional fields, or
attributes, to the token itself.

[1]
https://github.com/cloudfoundry/uaa/blob/9b5c13d793ebfe358e26559cedc6b528a557b43f/server/src/main/java/org/cloudfoundry/identity/uaa/oauth/UaaTokenServices.java#L493-L497
[2] https://www.pivotaltracker.com/story/show/102090344

Guillaume.

Guillaume,

We just realized that you can remove any PII, personally identifiable
information, from tokens without us having to add new features

You just configure

jwt:
token:
claims:
exclude:
- authorities
- email
- user_name

in your uaa.yml file. Similar config exists for cf-release
We're closing the story as a "no change needed".


On Fri, Apr 1, 2016 at 1:12 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Great, thanks Filip!


Guillaume.

On Thu, Mar 31, 2016 at 9:50 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

yes, they are always returned.

introducing an option sounds like a good idea for the systems that wish
to turn it off, thanks for the idea.

https://www.pivotaltracker.com/story/show/116726159

Filip


On Thu, Mar 31, 2016 at 1:39 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Thanks Filip for your answer. Wouldn't it make sense to progressively
change this behavior, possibly controlled by a configuration option to give
clients time to handle this incompatible change?

Scanning quickly through the code I suspect the username and email
fields are systematically returned in the access token, regardless of the
presence of the openid scope (I still have to double check by actually
testing it), therefore disclosing some user identity without his/her
consent.

Guillaume.

On Thu, Mar 31, 2016 at 3:03 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

The access token used to double down as an identity token before
OpenID Connect was standardized, now that we have implemented id_token, we
don't really need it. but removing it would cause an backwards incompatible
change.


Filip


On Thu, Mar 31, 2016 at 6:50 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

I wonder the rationale for apparenty uaa-specific [0] user-related
fields in the access token (username, email [1]) while they are now
returned in a standard maneer in the openidconnect id token.

Is it something that would change in the future ([2] seemed similar
decoupling) ? Or is it a standard practice that avoids clients to request
the idtoken to get access to basic user identity ?

Thanks in advance,

Guillaume.

ps: please let me know if such questions are better suited for a GH
issue on the UAA repo.

[0]
https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-Tokens.md#getting-started

Some of these fields are described in the JSON web tokens

specification. However, the vendor may add additional fields, or
attributes, to the token itself.

[1]
https://github.com/cloudfoundry/uaa/blob/9b5c13d793ebfe358e26559cedc6b528a557b43f/server/src/main/java/org/cloudfoundry/identity/uaa/oauth/UaaTokenServices.java#L493-L497
[2] https://www.pivotaltracker.com/story/show/102090344

Guillaume.

thanks Filip for the update.

I'm curious to know if the various CF components using UAA (e.g. cc) are
already using openid-connect to access PII and thus is the cf-release
default value for the excluded claims could indeed email and user_name, or
whether this is planned and can be watch in their respective backlog (I yet
have to check).

Seems the default value is empty for now in cf-release
http://bosh.io/jobs/uaa?source=github.com/cloudfoundry/cf-release&version=236

Guillaume.


Guillaume.

On Tue, Apr 19, 2016 at 4:16 PM, Filip Hanik <fhanik(a)pivotal.io
<javascript:_e(%7B%7D,'cvml','fhanik(a)pivotal.io');>> wrote:

Guillaume,

We just realized that you can remove any PII, personally identifiable
information, from tokens without us having to add new features

You just configure

jwt:
token:
claims:
exclude:
- authorities
- email
- user_name

in your uaa.yml file. Similar config exists for cf-release
We're closing the story as a "no change needed".


On Fri, Apr 1, 2016 at 1:12 AM, Guillaume Berche <bercheg(a)gmail.com
<javascript:_e(%7B%7D,'cvml','bercheg(a)gmail.com');>> wrote:

Great, thanks Filip!


Guillaume.

On Thu, Mar 31, 2016 at 9:50 PM, Filip Hanik <fhanik(a)pivotal.io
<javascript:_e(%7B%7D,'cvml','fhanik(a)pivotal.io');>> wrote:

yes, they are always returned.

introducing an option sounds like a good idea for the systems that wish
to turn it off, thanks for the idea.

https://www.pivotaltracker.com/story/show/116726159

Filip


On Thu, Mar 31, 2016 at 1:39 PM, Guillaume Berche <bercheg(a)gmail.com
<javascript:_e(%7B%7D,'cvml','bercheg(a)gmail.com');>> wrote:

Thanks Filip for your answer. Wouldn't it make sense to progressively
change this behavior, possibly controlled by a configuration option to give
clients time to handle this incompatible change?

Scanning quickly through the code I suspect the username and email
fields are systematically returned in the access token, regardless of the
presence of the openid scope (I still have to double check by actually
testing it), therefore disclosing some user identity without his/her
consent.

Guillaume.

On Thu, Mar 31, 2016 at 3:03 PM, Filip Hanik <fhanik(a)pivotal.io
<javascript:_e(%7B%7D,'cvml','fhanik(a)pivotal.io');>> wrote:

The access token used to double down as an identity token before
OpenID Connect was standardized, now that we have implemented id_token, we
don't really need it. but removing it would cause an backwards incompatible
change.


Filip


On Thu, Mar 31, 2016 at 6:50 AM, Guillaume Berche <bercheg(a)gmail.com
<javascript:_e(%7B%7D,'cvml','bercheg(a)gmail.com');>> wrote:

Hi,

I wonder the rationale for apparenty uaa-specific [0] user-related
fields in the access token (username, email [1]) while they are now
returned in a standard maneer in the openidconnect id token.

Is it something that would change in the future ([2] seemed similar
decoupling) ? Or is it a standard practice that avoids clients to request
the idtoken to get access to basic user identity ?

Thanks in advance,

Guillaume.

ps: please let me know if such questions are better suited for a GH
issue on the UAA repo.

[0]
https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-Tokens.md#getting-started

Some of these fields are described in the JSON web tokens

specification. However, the vendor may add additional fields, or
attributes, to the token itself.

[1]
https://github.com/cloudfoundry/uaa/blob/9b5c13d793ebfe358e26559cedc6b528a557b43f/server/src/main/java/org/cloudfoundry/identity/uaa/oauth/UaaTokenServices.java#L493-L497
[2] https://www.pivotaltracker.com/story/show/102090344

Guillaume.