JWT 1.1 Spec draft

222 views
Skip to first unread message

David Blevins

unread,
Apr 27, 2018, 10:38:49 PM4/27/18
to MicroProfile
I've drafted up a new chapter for the configuration options being added to MicroProfile JWT 1.1.  See chapter 9.

I made some slight changes from what was discussed and I'm happy to revert.  When laid out they seem to make sense.

 - mp.jwt.verify.publickey.location favors file system then classloader
 - JWKs can be supplied in either text or base 64 forms

Both fairly minor.  Other than that I added several situations around DeploymentExceptions, which we never really addressed, so definitely do check those out.  I leaned fairly conservatively with them with the thinking it would be easier to relax them later, but adding them later and making things more strict would be problematic.  Particularly, setting both `mp.jwt.verify.publickey.location` and `mp.jwt.verify.publickey` is a DeploymentException rather than one of them being ignored.

The suggestion was made that both `mp.jwt.verify.publickey.location` and `mp.jwt.verify.publickey` could be the same property.  Looking at all the rules around key formats and urls, it would definitely be a lot of magic for one property.

microprofile-jwt-auth-spec-1.1-draft.pdf

Ladislav Thon

unread,
Apr 28, 2018, 8:21:15 AM4/28/18
to MicroProfile
2018-04-28 4:38 GMT+02:00 David Blevins <dble...@tomitribe.com>:
The suggestion was made that both `mp.jwt.verify.publickey.location` and `mp.jwt.verify.publickey` could be the same property.  Looking at all the rules around key formats and urls, it would definitely be a lot of magic for one property.

Looking at chapter 9, it's already pretty magical. If location required a prefix (classpath:, file:, http:), I don't think it would significantly increase cognitive load.

But DeploymentException in case both properties are present is good too.

LT
 

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/ECE1BFE6-5F42-462A-9B17-931A2647096E%40tomitribe.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/ECE1BFE6-5F42-462A-9B17-931A2647096E%40tomitribe.com.
For more options, visit https://groups.google.com/d/optout.


Scott Stark

unread,
May 1, 2018, 4:54:08 AM5/1/18
to Eclipse MicroProfile
We also need to support the JWKS format with the key selected by the kid claim of the MP-JWT.
I'll have to add some tests of including a base64 encoded JWK(S). I have tests of the other variations ready, so as soon as I add those I would like to put out an RC1 release. Can you either check in or do a PR for the spec changes you have?

In terms of requirements on the JWK(S), for public key one typically sees a "use": "sig" attribute and an "alg": "xxx" attribute, which in our case would be required to be RSA256. Do we want to mandate these?

Scott Stark

unread,
May 1, 2018, 4:58:58 AM5/1/18
to Eclipse MicroProfile
I missed the supported key formats section where it mentions JWKS, but there is the question of the minimal attributes that need to be on the JWK object.

David Blevins

unread,
May 1, 2018, 1:43:48 PM5/1/18
to MicroProfile
On May 1, 2018, at 1:58 AM, Scott Stark <sst...@redhat.com> wrote:

I missed the supported key formats section where it mentions JWKS, but there is the question of the minimal attributes that need to be on the JWK object.

That should be section 9.2.2 second sentence:

"At minimum JWK formatted Public Keys must contain the kty field. RSA Public Keys must contain the n and e fields."

We can definitely update more if needed.


-David


--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

Scott Stark

unread,
May 1, 2018, 3:48:40 PM5/1/18
to Eclipse MicroProfile
Should we require more is the question. I'm inclined to require the "alg": "RS256" since that is all we support, but not the "use" as this is a potentially multivalued parameter that I don't see a real benefit to. 

David Blevins

unread,
May 1, 2018, 7:02:49 PM5/1/18
to microp...@googlegroups.com
On May 1, 2018, at 12:48 PM, Scott Stark <sst...@redhat.com> wrote:

Should we require more is the question. I'm inclined to require the "alg": "RS256" since that is all we support, but not the "use" as this is a potentially multivalued parameter that I don't see a real benefit to. 

Got it.  The 'alg' header is optional in the JWK specification, so my gut would favor it also being optional for us.  Primarily out of fear some users would be forced to intercept and edit JWK/S coming from their issuer.

What do you think about Ladislav's idea of a "classpath:" URL prefix so people had a way to be deterministic with the location?  I don't necessarily see the advantage of taking away non-url based paths, but as we do have "file:" and "http:", I could see the argument for "classpath:".  Not sure I feel strongly about it one way or the other, however.


-David

On Tuesday, May 1, 2018 at 10:43:48 AM UTC-7, David Blevins wrote:

On May 1, 2018, at 1:58 AM, Scott Stark <sst...@redhat.com> wrote:

I missed the supported key formats section where it mentions JWKS, but there is the question of the minimal attributes that need to be on the JWK object.

That should be section 9.2.2 second sentence:

"At minimum JWK formatted Public Keys must contain the kty field. RSA Public Keys must contain the n and e fields."

We can definitely update more if needed.


-David



--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

Chunlong Liang

unread,
May 1, 2018, 11:43:00 PM5/1/18
to Eclipse MicroProfile

Regarding "In the absence of a matching kid, all keys in the set will be tried in the order listed." in section 9.3.
I would like to make this an error if there are multiple keys in JWK key set, and kid is missing from JWK or there is no matching kid. If there is only one key in JWK key set, kid is optional. This proposal is consistency with OIDC spec http://openid.net/specs/openid-connect-core-1_0.html#SigEnc

Scott Stark

unread,
May 2, 2018, 12:57:38 AM5/2/18
to Eclipse MicroProfile
Right, good point and that brings up the kid property requirements. While optional, for a JWKS with multiple keys it should be a validation error a Chunlong points out. We can't verify matching until a request with a JWT comes in, but I expect a 401 error with some detail message about no way to locate the signer public key at that point.

Scott Stark

unread,
May 2, 2018, 12:59:58 AM5/2/18
to Eclipse MicroProfile
Good point about the JWK/S issuer format as I don't have enough familiarity on that to say what a good practice is, so alg as optional is fine.

I do think an explicit classpath: prefix is good.

David Blevins

unread,
May 2, 2018, 7:31:29 PM5/2/18
to MicroProfile
That works for me as well.  So the updated rule is:

 - When there are multiple keys in the JWKS
     - `kid` must be present on each key.  If not, then DeploymentException
     - `kid` must be present on the JWT.  If not or if JWKS was dynamically obtained (http), then 401

I would probably add language that says any support for relaxing the kid requirement would be vendor-specific.

That about cover it?

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

Scott Stark

unread,
May 2, 2018, 7:38:50 PM5/2/18
to Eclipse MicroProfile
Yes, I believe that is it.

Scott Stark

unread,
May 3, 2018, 3:05:08 AM5/3/18
to Eclipse MicroProfile
The first pass at the config related tck tests has been merged. Are we ready for an RC1?

Ladislav Thon

unread,
May 3, 2018, 4:00:18 AM5/3/18
to MicroProfile
2018-05-03 9:05 GMT+02:00 Scott Stark <sst...@redhat.com>:
The first pass at the config related tck tests has been merged. Are we ready for an RC1?


No plans to fix #74 / #81 in 1.1?

LT

 

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

Scott Stark

unread,
May 3, 2018, 2:38:50 PM5/3/18
to Eclipse MicroProfile
I'll be making a pass through a number of issues marked for 1.1 in the coming week. The first release is focused on the config behaviors to allow implementors to have a look at the requirements to see if there are any concerns.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

David Blevins

unread,
May 3, 2018, 5:36:03 PM5/3/18
to MicroProfile, Jean-Louis MONTEIRO
Spec update pending, then clear on my side.

There was some talk internally that the `aud` claim was required in some way by the TCK.  Jean-Louis, can you clarify?

I checked the specification and it is marked as optional which matches my understanding from discussions last summer.
--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

Scott Stark

unread,
May 3, 2018, 10:15:04 PM5/3/18
to Eclipse MicroProfile
aud it not part of the RequiredClaimsTest test, but there are tests that verify if it is provided that it's value is available via injection of that claim.

David Blevins

unread,
May 16, 2018, 12:58:38 AM5/16/18
to Micro Profile
Ok, here is the latest update.  Just a tweek as discussed here on the list..

I've added a Future Directions, which is really nice-to-have and doesn't need to be complete. (we can just add future items in the future)

I think we should be good to roll the RC.


To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/cbbc72bd-a6ad-4f9c-ac5f-3419511d417b%40googlegroups.com.
microprofile-jwt-auth-spec.pdf

David Blevins

unread,
May 16, 2018, 1:04:39 AM5/16/18
to Micro Profile
Sorry, review this one.  I merged the future direction section I added with the one that was already there.

Now we're good.
microprofile-jwt-auth-spec.pdf

Chunlong Liang

unread,
May 16, 2018, 5:03:06 PM5/16/18
to Eclipse MicroProfile
Thanks David!

Here are my comments:

1. For the statement in section 9.1
"
Public Keys do not rotate frequently and storing them in the binary image or on disk is a realistic option for many environments.
"
There are token issuers that dynamically generate private/public every day (like Google), and does not use server's private key to sign. So maybe we should say
"
If signing Key is not rotated frequently, storing them in the binary image or on disk is a realistic option for many environments.
"

2. For the "Note" in section 9.2
"
Symmetrically signed JWTs such as HMAC-SHA256 (hs256) are explicitly not
supported, deemed insecure for a distributed Microservice architecture where
JWTs are expected to be passed around freely. Use of symmetric signatures would
require all microservices to share a secret, eliminating the ability to determine who
created the JWT.
"

Should we relax it to be "Using HS256 is Not Recommended and supporting HS256 is optional"? With JWK, you will not need manually distribute shared secret. The token issuer could publish the shared key in JWK, and protect the JWK endpoint with issuer's certificate.  See https://tools.ietf.org/html/rfc7517#appendix-A.3. We also noticed some Spring applications are still using HS256, and we should keep the interop option open"

3. For section 9.2.3
"
MicroProfile JWT implementations are required to throw a DeploymentException if a JWKS is supplied via static configiuration and contains multiple keys, but no kid.
MicroProfile JWT implementations are required to return a 401 at runtime in situations where a kid is either required or does not match.
"
Should we not do validation and throw exception here? and leave it to vendor. If runtime can not resolve the key, runtime will return 401 anyway. I prefer that Microprofile can work many existing deployment even it may not fully in MP-JWT format, we define what is required to be working, but we do not prevent other scenarios. For example, some token issued by Azure/ADFS still emit "x5t" as key identifier, but the payload has MP-JWT format.

4. For section 9.3.1
"
MicroProfile JWT implementations are required to throw a DeploymentException if neither mp.jwt.verify.publickey nor mp.jwt.verify.publickey.location are supplied.
"
We should not throw exception here, because today every vendor already has its own way to supply validation key. Also this restriction totally block symmetric key although it is not a desired algorithm.

5.
For "9.3.2.3. http: URL Scheme"

Should we limit the required support to JWK or JWKS only?

6. "9.3.3. mp.jwt.verify.issuer"
The statement  "In most cases relying on the digital signature check via the Public Key alone is sufficient to establish trust." is not always true. Some token issuer does not use server's private key to sign token, and it actually dynamically generate and rotate a key pair, and sign token with the private key. This signing strategy can be seen in OIDC, which may be why OIDC always require a matching "iss".

For this statement "If the mp.jwt.verify.issuer config property has not been set, any issuer or none at all is allowed.". Even if we want to allow any issuer, but we will still need "iss" is included in JWT with the format defined similar to OIDC (see http://openid.net/specs/openid-connect-core-1_0.html:
Issuer Identifier:  Verifiable Identifier for an Issuer. An Issuer Identifier is a case sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components.
)

6. In our early discussion, we talked about define a cookie name, "MPJWT" in addition to "Authorize Bearer ....". Are we going to document this? I know we also discuss cookie security issues, but that is not unique to MPJWT, all existing and known protection mechanism still apply to this cookie.







On Friday, April 27, 2018 at 9:38:49 PM UTC-5, David Blevins wrote:

Scott Stark

unread,
May 17, 2018, 12:27:22 AM5/17/18
to Eclipse MicroProfile
I have commented inline.


On Wednesday, May 16, 2018 at 2:03:06 PM UTC-7, Chunlong Liang wrote:
Thanks David!

Here are my comments:

1. For the statement in section 9.1
"
Public Keys do not rotate frequently and storing them in the binary image or on disk is a realistic option for many environments.
"
There are token issuers that dynamically generate private/public every day (like Google), and does not use server's private key to sign. So maybe we should say
"
If signing Key is not rotated frequently, storing them in the binary image or on disk is a realistic option for many environments.
"

That seems like a reasonable change. I updated it to something similar.
 

2. For the "Note" in section 9.2
"
Symmetrically signed JWTs such as HMAC-SHA256 (hs256) are explicitly not
supported, deemed insecure for a distributed Microservice architecture where
JWTs are expected to be passed around freely. Use of symmetric signatures would
require all microservices to share a secret, eliminating the ability to determine who
created the JWT.
"

Should we relax it to be "Using HS256 is Not Recommended and supporting HS256 is optional"? With JWK, you will not need manually distribute shared secret. The token issuer could publish the shared key in JWK, and protect the JWK endpoint with issuer's certificate.  See https://tools.ietf.org/html/rfc7517#appendix-A.3. We also noticed some Spring applications are still using HS256, and we should keep the interop option open"


This section is talking about the JWT signing algorithms as I understand it. For interop, I thought we did require RS256, and we do have a TCK test, InvalidTokenTest#callEchoBadSignerAlg that tests that a non-RS256 signed token fails. Perhaps this is not testing that it fails for the reason of an unsupported alg (which is HS256 in the test), since the shared key is not available, a server would not be able to validate it anyway. In section 4.1 we are saying that the JWT alg claim must be RS256. We also talk about this in section 6. I guess we need to clarify how the alg JOSE header parameter should be treated.

 
3. For section 9.2.3
"
MicroProfile JWT implementations are required to throw a DeploymentException if a JWKS is supplied via static configiuration and contains multiple keys, but no kid.
MicroProfile JWT implementations are required to return a 401 at runtime in situations where a kid is either required or does not match.
"
Should we not do validation and throw exception here? and leave it to vendor. If runtime can not resolve the key, runtime will return 401 anyway. I prefer that Microprofile can work many existing deployment even it may not fully in MP-JWT format, we define what is required to be working, but we do not prevent other scenarios. For example, some token issued by Azure/ADFS still emit "x5t" as key identifier, but the payload has MP-JWT format.


Chunlong, are you against the DeploymentException when the JWKS is given explicitly, rather than as a URI? I'm taking that is what David is meaning here as "static configuration". I agree one cannot necessarily validate a URI to a JWKS endpoint, and that situation cannot require a DeploymentException.

There is an example of a Azure/ADFS JWT header on this page that shows the use of the "x5t" parameter rather than kid 
{ "typ": "JWT", "alg": "RS256", "x5t": "kriMPdmBvx68skT8-mPAB3BseeA" }

 So perhaps validation of the kid should not be done as there are several alternative methods described for matching public/private keys in the JOSE Header section of the JWE RFC.


4. For section 9.3.1
"
MicroProfile JWT implementations are required to throw a DeploymentException if neither mp.jwt.verify.publickey nor mp.jwt.verify.publickey.location are supplied.
"
We should not throw exception here, because today every vendor already has its own way to supply validation key. Also this restriction totally block symmetric key although it is not a desired algorithm.


Right, we have existing TCK tests that produce deployments that have no META-INF/microprofile-config.properties that rely on the vendor TCK integration code to map the expected signer and issuer in whatever way is supported using the Arquillian ApplicationArchiveProcessor hook. Enforcing this would require all of the TCK tests to be updated to supply a META-INF/microprofile-config.properties, and MP-JWT 1.0 deployments would simply start to fail.
 
5.
For "9.3.2.3. http: URL Scheme"

Should we limit the required support to JWK or JWKS only?

Why do you bring up that question with respect to the URL Scheme section? Isn't that a more general question for the "9.2 Supported Public Key Formats" section?

 

6. "9.3.3. mp.jwt.verify.issuer"
The statement  "In most cases relying on the digital signature check via the Public Key alone is sufficient to establish trust." is not always true. Some token issuer does not use server's private key to sign token, and it actually dynamically generate and rotate a key pair, and sign token with the private key. This signing strategy can be seen in OIDC, which may be why OIDC always require a matching "iss".

For this statement "If the mp.jwt.verify.issuer config property has not been set, any issuer or none at all is allowed.". Even if we want to allow any issuer, but we will still need "iss" is included in JWT with the format defined similar to OIDC (see http://openid.net/specs/openid-connect-core-1_0.html:
Issuer Identifier:  Verifiable Identifier for an Issuer. An Issuer Identifier is a case sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components.
)

6. In our early discussion, we talked about define a cookie name, "MPJWT" in addition to "Authorize Bearer ....". Are we going to document this? I know we also discuss cookie security issues, but that is not unique to MPJWT, all existing and known protection mechanism still apply to this cookie.




I did add a simple section on cookie support.

Attached is the updated spec that we can discuss during tomorrow's call.

 
microprofile-jwt-auth-spec.pdf

David Blevins

unread,
May 17, 2018, 1:08:42 AM5/17/18
to microp...@googlegroups.com
On May 16, 2018, at 9:27 PM, Scott Stark <sst...@redhat.com> wrote:

I have commented inline.

On Wednesday, May 16, 2018 at 2:03:06 PM UTC-7, Chunlong Liang wrote:
Thanks David!

Here are my comments:

1. For the statement in section 9.1
"
Public Keys do not rotate frequently and storing them in the binary image or on disk is a realistic option for many environments.
"
There are token issuers that dynamically generate private/public every day (like Google), and does not use server's private key to sign. So maybe we should say
"
If signing Key is not rotated frequently, storing them in the binary image or on disk is a realistic option for many environments.
"

That seems like a reasonable change. I updated it to something similar.

Thanks, Scott!

 

2. For the "Note" in section 9.2
"
Symmetrically signed JWTs such as HMAC-SHA256 (hs256) are explicitly not
supported, deemed insecure for a distributed Microservice architecture where
JWTs are expected to be passed around freely. Use of symmetric signatures would
require all microservices to share a secret, eliminating the ability to determine who
created the JWT.
"

Should we relax it to be "Using HS256 is Not Recommended and supporting HS256 is optional"? With JWK, you will not need manually distribute shared secret. The token issuer could publish the shared key in JWK, and protect the JWK endpoint with issuer's certificate.  See https://tools.ietf.org/html/rfc7517#appendix-A.3. We also noticed some Spring applications are still using HS256, and we should keep the interop option open"


This section is talking about the JWT signing algorithms as I understand it. For interop, I thought we did require RS256, and we do have a TCK test, InvalidTokenTest#callEchoBadSignerAlg that tests that a non-RS256 signed token fails. Perhaps this is not testing that it fails for the reason of an unsupported alg (which is HS256 in the test), since the shared key is not available, a server would not be able to validate it anyway. In section 4.1 we are saying that the JWT alg claim must be RS256. We also talk about this in section 6. I guess we need to clarify how the alg JOSE header parameter should be treated.

I have the same perspective.  We've historically had consensus that RSA was the only blessed method as HMAC would require all microservices to have the secret key which means they are the issuer.  I wouldn't want to make a change that big at the last minute while we're attempting to get a release out the door to not miss the MicroProfile 1.4 window.


 
3. For section 9.2.3
"
MicroProfile JWT implementations are required to throw a DeploymentException if a JWKS is supplied via static configiuration and contains multiple keys, but no kid.
MicroProfile JWT implementations are required to return a 401 at runtime in situations where a kid is either required or does not match.
"
Should we not do validation and throw exception here? and leave it to vendor. If runtime can not resolve the key, runtime will return 401 anyway. I prefer that Microprofile can work many existing deployment even it may not fully in MP-JWT format, we define what is required to be working, but we do not prevent other scenarios. For example, some token issued by Azure/ADFS still emit "x5t" as key identifier, but the payload has MP-JWT format.


Chunlong, are you against the DeploymentException when the JWKS is given explicitly, rather than as a URI? I'm taking that is what David is meaning here as "static configuration". I agree one cannot necessarily validate a URI to a JWKS endpoint, and that situation cannot require a DeploymentException.

There is an example of a Azure/ADFS JWT header on this page that shows the use of the "x5t" parameter rather than kid 
{ "typ": "JWT", "alg": "RS256", "x5t": "kriMPdmBvx68skT8-mPAB3BseeA" }

 So perhaps validation of the kid should not be done as there are several alternative methods described for matching public/private keys in the JOSE Header section of the JWE RFC.

I suggest we put this in there using the same level defined in the JWK specification, which is "SHOULD" not "MUST".  I.e. using the kid in a set with multiple keys is a recommendation (you should do that), but not a requirement (you must do that).



4. For section 9.3.1
"
MicroProfile JWT implementations are required to throw a DeploymentException if neither mp.jwt.verify.publickey nor mp.jwt.verify.publickey.location are supplied.
"
We should not throw exception here, because today every vendor already has its own way to supply validation key. Also this restriction totally block symmetric key although it is not a desired algorithm.


Right, we have existing TCK tests that produce deployments that have no META-INF/microprofile-config.properties that rely on the vendor TCK integration code to map the expected signer and issuer in whatever way is supported using the Arquillian ApplicationArchiveProcessor hook. Enforcing this would require all of the TCK tests to be updated to supply a META-INF/microprofile-config.properties, and MP-JWT 1.0 deployments would simply start to fail.
 
5.
For "9.3.2.3. http: URL Scheme"

Should we limit the required support to JWK or JWKS only?

Why do you bring up that question with respect to the URL Scheme section? Isn't that a more general question for the "9.2 Supported Public Key Formats" section?

We had this discussion.  My thoughts are it isn't hard to support both, there's no clear winner and picking just one cuts our potential compatibility.

I'd definitely want to keep the public key "guessing" the same regardless if it came from a file or url.

6. "9.3.3. mp.jwt.verify.issuer"
The statement  "In most cases relying on the digital signature check via the Public Key alone is sufficient to establish trust." is not always true. Some token issuer does not use server's private key to sign token, and it actually dynamically generate and rotate a key pair, and sign token with the private key. This signing strategy can be seen in OIDC, which may be why OIDC always require a matching "iss".

For this statement "If the mp.jwt.verify.issuer config property has not been set, any issuer or none at all is allowed.". Even if we want to allow any issuer, but we will still need "iss" is included in JWT with the format defined similar to OIDC (see http://openid.net/specs/openid-connect-core-1_0.html:
Issuer Identifier:  Verifiable Identifier for an Issuer. An Issuer Identifier is a case sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components.
)

I'm not quite sure what the request is.  We definitely discussed that issuer is optional in the JWT specification which is why we agreed to make it optional in the configuration, but still allow for it be enforced.  https://tools.ietf.org/html/rfc7519#section-4.1.1

Is it the recommendation that when `iss` is supplied we only allow OIDC compatible issuers and block JWTs that may follow a different companion spec?

My hesitation there is it starts to eliminate OAuth implementations that are not OIDC based.



6. In our early discussion, we talked about define a cookie name, "MPJWT" in addition to "Authorize Bearer ....". Are we going to document this? I know we also discuss cookie security issues, but that is not unique to MPJWT, all existing and known protection mechanism still apply to this cookie.




I did add a simple section on cookie support.

I don't recall any cookie discussion, but I missed the first two or so calls.  Definitely not opposed to it.

I do wonder if we want something that isn't branded.  I.e. simply use "Bearer" as the cookie name to match the scheme.  On the same note, our code allows for "Bearer" as the header rather than just "Authorization: Bearer"

Do we want to tackle these topics in this rev or use them to make a roadmap for 1.2 and keep the momentum going?


-David

Chunlong Liang

unread,
May 18, 2018, 10:48:29 AM5/18/18
to Eclipse MicroProfile

Yesterday we did discuss "iss" claim, and I did agree to keep the statement as it is. But I am still not comfortable with it, and keep thinking about that statement. It is a common perception that JWT is more like a simple clone of SAML that issuer is always required as an identifier of assertion/token issuer. Also it is my experience that token signing key is not always the same as server's private key for SSL connection, so we should separate token signing key from token issuer. Even if signing key is server private key, you usually would need a name to name server/key.

For this reason, I would like to propose the following (last minute) change, which give us more option to define "iss" behavior in the future.

"If the mp.jwt.verify.issuer config property has not been set, any issuer or none at all is allowed."
To
"If the mp.jwt.verify.issuer config property has not been set, the issuer verification is vendor specific."

Scott Stark

unread,
May 18, 2018, 12:12:28 PM5/18/18
to Eclipse MicroProfile
The problem with that is that we are saying that there is no way to disable the verification of the iss claim in a vendor independent way. 

What if we instead said that setting the mp.jwt.verify.issuer config property to '*' disables iss claim validation and MP-JWT with any iss claim, or none must be accepted?
If the problem is that there must be an iss claim in the MP-JWT, then I think we are stuck.

Chunlong Liang

unread,
May 18, 2018, 2:51:57 PM5/18/18
to microp...@googlegroups.com
Explicitly setting mp.jwt.verify.issuer config property to '*' (even some other keyword is fine) to disable issuer checking is a good solution.

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/IVDoXw12qXo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/d3b78d8d-3209-4736-9fab-aea02feb8d49%40googlegroups.com.

David Blevins

unread,
May 18, 2018, 9:14:27 PM5/18/18
to microp...@googlegroups.com
The trick with "*" is it doesn't address what happens if a user does nothing, so the default case would still be vendor specific.  I'm not a fan of establishing "*" as an explicit way to say java.util.Optional values should be null for MP Config variables.  We wouldn't be able to do it consistently everywhere, so I think it would grow strangely over time.

We should yank `mp.jwt.verify.issuer` for this release if we can't agree on an approach that makes us all comfortable.

We can get 1.1 out the door and keep discussing.  That would be much better than forcing one of us to implement something we don't want or defining something as vendor specific.


You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

David Blevins

unread,
May 18, 2018, 11:06:05 PM5/18/18
to microp...@googlegroups.com
Here's an updated version of the specification in case this is the direction we want to go.

microprofile-jwt-auth-spec.pdf

Scott Stark

unread,
May 19, 2018, 3:59:40 PM5/19/18
to Eclipse MicroProfile
I agree with comment about "*" being a potential rathole.

As I see it we have 3 usecases:
  1. An MP-JWT 1.0/1.1 deployment with no MP configuration information in the mp.jwt.* namespace
  2. An MP-JWT 1.1 deployment with an mp.jwt.verify.publickey.* value and a mp.jwt.verify.issuer value.
  3. An MP-JWT 1.1 deployment with an mp.jwt.verify.publickey.* value and no mp.jwt.verify.issuer value
If there was an acceptable value for case 2 that represented the situation where no iss validation was to be performed, that could be the default and subsume case 3.
Does the empty value/zero length string satisfy that?

On Friday, May 18, 2018 at 6:14:27 PM UTC-7, David Blevins wrote:
The trick with "*" is it doesn't address what happens if a user does nothing, so the default case would still be vendor specific.  I'm not a fan of establishing "*" as an explicit way to say java.util.Optional values should be null for MP Config variables.  We wouldn't be able to do it consistently everywhere, so I think it would grow strangely over time.

We should yank `mp.jwt.verify.issuer` for this release if we can't agree on an approach that makes us all comfortable.

We can get 1.1 out the door and keep discussing.  That would be much better than forcing one of us to implement something we don't want or defining something as vendor specific.


-- 
David Blevins

On May 18, 2018, at 11:51 AM, Chunlong Liang <chance...@gmail.com> wrote:

Explicitly setting mp.jwt.verify.issuer config property to '*' (even some other keyword is fine) to disable issuer checking is a good solution.
On Fri, May 18, 2018 at 11:12 AM, Scott Stark <sst...@redhat.com> wrote:
The problem with that is that we are saying that there is no way to disable the verification of the iss claim in a vendor independent way. 

What if we instead said that setting the mp.jwt.verify.issuer config property to '*' disables iss claim validation and MP-JWT with any iss claim, or none must be accepted?
If the problem is that there must be an iss claim in the MP-JWT, then I think we are stuck.

On Friday, May 18, 2018 at 7:48:29 AM UTC-7, Chunlong Liang wrote:

Yesterday we did discuss "iss" claim, and I did agree to keep the statement as it is. But I am still not comfortable with it, and keep thinking about that statement. It is a common perception that JWT is more like a simple clone of SAML that issuer is always required as an identifier of assertion/token issuer. Also it is my experience that token signing key is not always the same as server's private key for SSL connection, so we should separate token signing key from token issuer. Even if signing key is server private key, you usually would need a name to name server/key.

For this reason, I would like to propose the following (last minute) change, which give us more option to define "iss" behavior in the future.
"If the mp.jwt.verify.issuer config property has not been set, any issuer or none at all is allowed."
To
"If the mp.jwt.verify.issuer config property has not been set, the issuer verification is vendor specific."



--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/IVDoXw12qXo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

Chunlong Liang

unread,
May 21, 2018, 10:58:38 AM5/21/18
to microp...@googlegroups.com
We believe that we should not trust any issuer by default.  Servlet 3.1 spec defines '**' instead of '*'
<role-name>**</role-name>
to give permission to any authenticated user.
If "*" is a bad choice, could we define some key word like  "PermitAll", or "ANY", "ALL"?

To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/84779309-aefc-4815-b1c4-11c9f28863ca%40googlegroups.com.

Scott Stark

unread,
May 22, 2018, 8:16:45 PM5/22/18
to Eclipse MicroProfile
Ok, so you would like to view a missing or empty iss config as essentially a failure condition because you won't accept any token iss value, missing or not. Is that your runtime default? Essentially you require some configuration of what the allowed iss values are, correct?

It sounds like the default for Tomitribe may be the opposite, if not specified, don't validate.

What if instead of overloading the mp.jwt.verify.issuer value to have a setting that indicates iss validation should be disabled, we simply add a boolelan mp.jwt.verify.requireiss config property. If this is missing, then the deployment is subject to vendor specific defaults. If set to true, then the token iss will be validated and it will be validated against the mp.jwt.verify.issuer setting. If set to false, then any token iss value will be accepted, and any mp.jwt.verify.issuer config value is ignored for the purposes of validation.

Chunlong Liang

unread,
May 23, 2018, 12:24:30 AM5/23/18
to microp...@googlegroups.com
I am OK if user has to explicitly disable "iss" checking.Your proposal is fine to us, and it is similar to my initial suggestion that behavior is vendor specific if issuer is not configured.

Both SAML and OIDC tokens explicitly require issuer checking, and most commercial authentication service vendors issue JWT with "iss" claim. One reason is that signing key is not necessary issuer's private key which is different from our assumption that token is signed by issuer's private key.  I strongly feel that we should follow existing SAML and OIDC security/trust model.

To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/49a5fec5-3705-46a9-8793-575c07bbb854%40googlegroups.com.

Jean-Louis Monteiro

unread,
May 23, 2018, 8:16:18 PM5/23/18
to MicroProfile
Hey Scott,

I would also prefer an explicit setting for disabling the iss checking.

I dislike the ** or any other kind of hardcoded iss that one has to recall it means disable or all.

I don't think someone mentioned, but we are speaking about disabling the iss checking. Which to me implies, what ever there is an iss claim or not, we won't even look at it.

As opposed to ** for instance which could meant, iss needs to be there but I don't care about the value. Again I hate this kind of hardcoded constants that change the behavior.

Anyway, +1 for specific setting to disable the iss checking. By default it should be true so that we check the issuer.






To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAJNN2AkiZazLin%3D%2BjVDgvcoEc9mmJ%3DcSiFa4O90VzKSTdvAdQQ%40mail.gmail.com.

Chunlong Liang

unread,
May 23, 2018, 11:22:35 PM5/23/18
to microp...@googlegroups.com
I agree with Jean-Louis's assessment that "iss" checking is required by default,  unless checking is disabled by setting mp.jwt.verify.requireiss="false". The property mp.jwt.verify.requireiss = "true" by default.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAPkio3E2AMRfc33D7SQ%2BCrZJZ7yzgY56G0_mKGayJyaUixU%2BvA%40mail.gmail.com.

David Blevins

unread,
May 24, 2018, 3:14:34 AM5/24/18
to microp...@googlegroups.com
My high-level concern is this is a bottom-line question on how we want to lean our defaults, to the JWT specification or the OIDC specification.  I wouldn't want to do a mix.  I'd also want to make sure the pattern we used here could deal with that entire use case and topic.  i.e. if we put additional "required" flags everywhere, we'd need to be happy continuing that pattern consistently for everywhere the JWT and OIDC specifications disagree.  We'd also need a clear and consistent set of defaults.  We should also examine how many we'd need -- how often do these specifications disagree.

Having that conversation at the finish line one month after the "iss (optional)" draft went up online for review feels like rushing.  My preference would be to leave it in Future Directions and table to MP JWT 1.2.

Chunlong Liang

unread,
May 24, 2018, 10:33:36 AM5/24/18
to microp...@googlegroups.com
I consider MP-JWT is a profile over JWT, and it is like SAML Single-Sign On profile over SAML ().  Given that "iss" is common in most JWT used today, and issuer checking has been common practice in self-contained and verifiable tokens (SAML, OIDC, and many profiles like UMA), I strongly recommend that we check "iss" by default (so we do not create a sense that MP-JWT is less secured than SAML or OIDC), while offer an option not to check "iss".

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/IVDoXw12qXo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/1766A305-05A4-4620-9DC6-2B2DD04A6CAE%40tomitribe.com.

Kevin Sutter

unread,
May 24, 2018, 2:11:02 PM5/24/18
to Eclipse MicroProfile
I'm not a security expert, but this seems like a good compromise.  Perform the issuer verification by default, but provide this property (mp.jwt.verify.requireiss) to explicitly enable or disable this verification.  Wouldn't this approach satisfy the participants?  And, it could still be part of JWT 1.1?

Thanks,
Kevin

Scott Stark

unread,
May 25, 2018, 1:45:06 AM5/25/18
to Eclipse MicroProfile
I understand what you are driving at, but the feeling I'm getting from the JWT issuer's in use is that iss is most commonly provided. If you look at the 75 JWT libraries listed on jwt.io, 43 of them have support for iss validation, and 6/6 of the Java language libs do. It feels like we have failed to handle the two most common inputs for validation of JWT's if we don't have a vendor independent mechanism to define the handling of the signer public key and the token iss claim.

Jean-Louis Monteiro

unread,
May 28, 2018, 11:17:30 AM5/28/18
to MicroProfile
Looks like we have to discuss and do some home work on this.

I'm ok to postpone to 1.2.


To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/1766A305-05A4-4620-9DC6-2B2DD04A6CAE%40tomitribe.com.

Scott Stark

unread,
May 29, 2018, 11:10:53 AM5/29/18
to Eclipse MicroProfile
So the 1.1-RC2 put out this weekend documents and tests the compromise approach based on the mp.jwt.verify.requireiss config property. Unfortunately only 3 implementors (Red Hat, IBM, Tomitribe) have been contributing to the most recent discussions, so is Tomitribe vetoing this change and wanting to rollback to the 1.1-RC1 behavior of having the mp.jwt.verify.issuer config property be a future direction?

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/IVDoXw12qXo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

Chunlong Liang

unread,
May 29, 2018, 1:53:12 PM5/29/18
to microp...@googlegroups.com
Using mp.jwt.verify.requireiss config property to enable and disable issuer checking is a good compromise, I think we should move forward to ratify RC-2. Given that the security design principle is not to trust any thing by default, and most issued token profiles (SAML web browser SSO, WS-Security SAML profile, and Openid Connect Relying Party) have issuer verification required by default, we should follow this common pattern to check JWT issuer by default.

To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/852ebcd7-a346-4d03-a3dd-ca388e8d5183%40googlegroups.com.

Scott Stark

unread,
May 29, 2018, 3:31:30 PM5/29/18
to Eclipse MicroProfile
That is where we are at as well since this is the situation with the majority of our users. The point of pushing for a vendor independent solution for the iss claim is that without it, we really have not solved the configuration problem for the majority of out users.

David Blevins

unread,
May 31, 2018, 3:15:15 PM5/31/18
to MicroProfile
Hi all.  Traveling at the moment.  If we can't agree if `iss` should be required or not, my preference would be:

 - to concede that for this release it is required and revisit this in 1.2
 - yank the proposed `mp.jwt.verify.requireiss` until that discussion completes

The text below not necessary for 1.1, I'm just adding some color onto where my prior request for more time originates. 

The spirit behind `mp.jwt.verify.requireiss` is not bad, but the property format feels odd and I don't think will grow well over time.  It feels odd to have the issuer value under `mp.jwt.verify.issuer` and a boolean under a completely different `mp.jwt.verify.requireiss` property.  We're referring to the issuer as both 'iss' and 'issuer' which is inconsistent.  Slightly more preferable would be `mp.jwt.verify.issuer.required` so all settings related to issuer are under the same tree.

Alternatively, if we do want to follow the format of referring to claims via their short name in configuration properties, we could perhaps have:

 - `mp.jwt.verify.claim.iss`
 - `mp.jwt.verify.claim.iss.required`

This format might grow better over time. 

 - `mp.jwt.verify.claim.iss`
 - `mp.jwt.verify.claim.iss.required`
 - `mp.jwt.verify.claim.aud`
 - `mp.jwt.verify.claim.aud.required`
 - `mp.jwt.verify.claim.groups`
 - `mp.jwt.verify.claim.groups.required`

Using a `mp.jwt.verify.claim.*` namespace could potentially allow us use the Config API to list the properties under the `mp.jwt.verify.claim.` and have all sub entries processed as claims using the format:

 - `mp.jwt.verify.claim.<claim> = <regex>`
 - `mp.jwt.verify.claim.<claim>.required = <boolean>`

I still find the `required` flag strange as the Config API allows for the use of java.util.Optional.  With the added `required` property, we're saying the JWT specification never intends to use this feature for any configuration options.  That feels strange.  Similarly, if we did want to allow some sort of pattern matching in an attempt to support checking any kind of claim, then Chunlong's original "*" might not actually be that bad. It would essentially be ".*"

Yet another alternative is there are perhaps many claims that may be required.  I spoke with a user after my security talk this week who asked how they could require a custom claim.  That's a good question.  They weren't a fan of having to copy/paste optional checking in all their JAX-RS endpoint methods.  This might give us:

 - `mp.jwt.verify.claims.required=sub,iss,color,groups,name,age`

Slightly more attractive and could potentially allow one to specify many required claims, standard or custom.  This would essentially give us a "profile" of required claims which could better suit people who would like to be strict to the OIDC set of claims.

Again, I'll restate my preference would be to leave issuer checking entirely vendor specific until we have some game plan on how we'll handle other claims and OIDC in general.  I feel we have largely focused on the key configuration and am 100% confident there, but not quite as confident we have considered the right things for claims configuration.  If everyone else is 100% confident, let's go forward with `mp.jwt.verify.issuer` in 1.1.  My request would be to at least leave `mp.jwt.verify.requireiss` out for 1.1 as I feel that would be immediate legacy when we do consider more claims in 1.2.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

Scott Stark

unread,
May 31, 2018, 3:42:15 PM5/31/18
to Eclipse MicroProfile
Ok, so if we do add the `mp.jwt.verify.issuer` config property, and require that for validation, don't add the `mp.jwt.verify.requireiss` config property now, which leaves any option to disable iss validation vendor specific in this release, and we revisit defining an ability to enable/disable validation at a later time I think satisfies everyone. I'll double check with Chunlong.

Chunlong Liang

unread,
May 31, 2018, 5:04:51 PM5/31/18
to microp...@googlegroups.com
This is a good compromise, let us get it done.


--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/IVDoXw12qXo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/f78d482c-0f67-47f8-b100-7a1f3f073c59%40googlegroups.com.

Scott Stark

unread,
May 31, 2018, 5:16:56 PM5/31/18
to Eclipse MicroProfile
Ok, I'm updating the spec and tck to reflect this and will have the release out tonight or tomorrow morning.
Thanks everyone.

Jean-Louis Monteiro

unread,
May 31, 2018, 5:26:18 PM5/31/18
to MicroProfile
Great.

Thanks everyone.

And thank you Scott.


--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/f598f949-232e-4507-9767-a6251ad9108c%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages