JWT Token definition for Interoperability

[Ken Finnigan]

All,

At the JavaOne BOF we discussed a good first step towards Interoperability between all the MicroProfile runtimes would be the ability to accept/produce a JWT token that can be passed into and between us.

We had proposed keeping the amount of data defined for Interoperability within the token being limited to Principals and Roles.

In defining the data within the token how does everyone feel about aligning the names with those of a specification, even if we're not supporting the entirety of a specifications definition? Such as OpenID Connect [1].

Regards

Ken

[1] - http://openid.net/specs/openid-connect-core-1_0.html#IDToken

[Pedro Igor]

+1. I think aligning with an existing and well known standard is the best way to go. JWT is just perfect for that.

The ID Token already provides a standard set of claims to represent identities across different systems. I would say that you can should consider all claims marked as "REQUIRED". The reason for that is that token-based authentication has very specific security considerations such as signatures/encryption (JOSE) and expiration, audience and issuer restrictions.

Roles are really context specific and don't have a corresponding claim in the ID Token. In fact, role mapping is a secondary concern when dealing JWTs given that everything is represented as claim. That said, roles can be just a claim within a JWT or a result of the processing of other claims.

I think is worthy mentioning that OpenID Connect (which is based on oAuth2) use cases are supported by two types of tokens: the ID Token itself and the Access Token. Spec wise, these two tokens are used by distinct audiences where the first is targeted for client applications and the latter for resource servers (which expose the APIs you want to access). I think what you want to achieve here is a mix of both worlds where the microprofile token will contain both identity and access information.

Regarding what you said about "the ability to accept/produce a JWT token". Do you really want to *produce* JWTs or just rely on an IdP (e.g.: Keycloak) for that ? In other words, just define the minimum claims supported by microprofile in order to guarantee Interoperability with different IdPs. 

Regards.

Pedro Igor

[Alasdair Nottingham]

I'm not convinced that we should put roles in a JWT, roles are very application specific so I don't think they have meaning between services. 

I also wonder if there should be constraints about how to use JWT, like which encryption standards should be used. 

Alasdair Nottingham

--
You received this message because you are subscribed to the Google Groups "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.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b2b6f36d-9590-4620-ad95-ddc2d761fb16%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Pedro Igor]

Yes, you are right. Each system has its own set of roles. But if I understood the idea correctly, what we are discussing here is not really related with defining roles but how systems can obtain them from a token in a standard way. So systems (probably belonging to the same organization and/or security domain) can rely on the same *claim* (eg.: "roles" : ["A", "B", "C"]) to extract roles.

In fact, you can even build roles from other attributes within a token. In this case, apps may also perform some local role mapping based on the claims within the token. A good example for that is what we have today in WildFly Elytron. There, identities are basically attribute-based where roles, permissions, groups and etc can be mapped based on attributes.

[Boleslaw Dawidowicz]

I understand that in *micro* profile you may not want to include whole big standards. Although I do believe it would be good to align with a subset of something which is properly thought out and polished around modern Apps/Services/APIs requirements around authentication - like OpenID Connect. There is whole multi year journey which brought us to current stage - with SAML, original OpenID, OAuth 1.x and OAuth2 to not mention few others which are now forgotten. Good to keep this in mind and learn from it. 

OAuth2 while very flexible and generic is actually also fairly painful as every provider has its own set of specifics around implementation - including things you are mentioning around security of token itself. Little known fact - OAuth2 actually doesn't even mandate usage of JWT. Token format is unspecified. Precise one in form of JWT comes with OpenID Connect spec. Nowadays it is easy to leverage libs and frameworks for all of this although few years back if you wanted to integrated with all Social Providers (Google, Facebook, Twitter, etc.) via OAuth2 in your application it has been actually been fairly painful experience. Because of great level of freedom and flexibility which has been left for them by the standard and little nuances in which this resulted. 

If you align with subset of existing standard - like OIDC - then you can easily leverage a lot of existing code and solutions and avoid a lot of trouble down the road. 

[Chunlong Liang]

I would expect JWT has reasonable short life time. After several hops of propagation, JWT can expire before calling next micro service. Should JWT contain some claim that can be used to renew/reissue JWT without user engagement? Maybe JWT contains some claim that can be used to refresh JWT in token service.

[Kevin Sutter]

I would really like to see a user scenario defined for this JWT propagation.  I'm not an expert with JWT and I'd like to understand how and when and why these JWT tokens would be used in MicroProfile.  Many of the early comments on this thread are jumping right into the problems or issues with using JWT.  And, with Chunlong's recent post, I'm wondering how these JWT tokens would be used without timing out.  Thanks!

Kevin

[Boleslaw Dawidowicz]

I agree about defining use cases you want to primarily address. Still I would assume this goes around modern type of apps - like implementing backend for mobile or client side apps, micro services type of architectures with one service invoked by mobile application calling other service and etc. All of this comes with rich set of issues around token expiration, refresh, invalidation and session management in general. 

This is the main reason I am suggesting some degree of alignment with existing specs. Biggest benefit of OAuth2/OIDC spec combo is well though answer for authorization and token exchanges around wide set of such modern architecture related use cases. Therefore I would be disappointed to see this group coming up with something totally custom and reinventing the wheel here. I believe that even if you start "light" and "small" and addressing limited set of use cases you will quickly hit very similar set of issues those specs are trying to address. 

[Stian T]

JWT is not a solution. It's just a token format.

A much better standpoint would be to align with OpenID Connect. There may be some extensions on top of OpenID Connect that could be useful like defining optional additional claims.

Whatever solution you come up with should:

* Require a OpenID Connect IdP

* Support existing OpenID Connect RP libraries

* Fully align with OpenID Connect or potentially extending OpenID Connect, but do NOT try to invent your own approach

[Werner Keil]

+1

There seems to be one, maybe two companies at most behind it. Selling tokens, certificates etc. and also hosting the jwt.io site.

We saw OpenID practically die before a company as big as Google went to its mercy and brought it back to life as an extension to OAuth2 under "Connect".

I would probably see discussions about the relevance of JWT support in the upcoming JSON-P version (1.1) and maybe so some extent in JSR 375 (Security) or a follow-up Security standard slated for Java EE 9.
Especially on the JSON-P side, once it's final an updated Microprofile revision would likely just bump up the version number of an initial dependency and get support for it, but hard to say if it's worth an extra effort.

Should there be some "incubator" after transition to Eclipse is done, then I could imagine that was also worth a "playground", but not sure, if it'll reach production quality or not.

Werner

[Chunlong Liang]

Would like to see more discussion on JWT interoperability. Say we agree that the JWT token will be  align with ID_TOKEN defined in OpenID Connect, and we need a profile or framework for interoperability. For simplicity, let us limit the scope of this profile to token data only. The profile could be similar to web service security saml token profile, or http://openid.net/specs/openid-heart-uma-1_0.html. We would not worry about code portability for now, and discuss codes portability in aligning with JSON-P or JSR375 later in a different profile.

The ID_TOKEN has five required claims: iss, iat, exp, aud, and sub.  If resource server is using the JWT for authorization, I think the following claims are also important
groups: user’s group memberships for authorization if authorization uses group information.
idp/authnby: If the issuer delegates authentication to 3rd party IdP
upn: user principal name. Provide a principal name if it is different from sub.
scope: authorized scopes.
azp: The client identifier of the authorized client.

wonder if we can start jwt token data profile draft?

On Friday, October 21, 2016 at 2:26:15 PM UTC-5, Ken Finnigan wrote:

[sst...@redhat.com]

Just for context, here is the IDToken opening sentences from the OpenID Connect Core 1.0  Ken references:

The primary extension that OpenID Connect makes to OAuth 2.0 to enable End-Users to be Authenticated is the ID Token data structure. The ID Token is a security token that contains Claims about the Authentication of an End-User by an Authorization Server when using a Client, and potentially other requested Claims. The ID Token is represented as a JSON Web Token (JWT) [JWT].

The JWT format is further detailed at:

https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32

[Werner Keil]

Then please try to stick to the IETF recommendations, that should make any other frameworks or Java libraries (e.g. in a JSR like 375 or a successor) fairly compatible and inter-operable.

[sst...@redhat.com]

Actually, the latest JWT IETF spec is the following, not the draft 32 version that the OpenID page references:

https://tools.ietf.org/html/rfc7519

[Werner Keil]

Yes, that's the same RFC they advertise on https://jwt.io/

[sst...@redhat.com]

I think the minimum starting use case is that a user has a workflow that involves 2 or more micro services. They are using an IdP to produce a JWT that has a subject and workflow associated roles.

What they need is the ability to configure the micro services to:

1. accept that JWT is valid. This goes to defining acceptable signatures and encryption. A default implementation of a javax.security.auth.message.module.ServerAuthModule that illustrates this would be needed for a compatibility test.

2. Some security configuration definition that allows for the mapping of the subject and workflow roles into the security domains of the containers hosting the micro services.

It seems like the aud(iences) field of the token could be used for the purpose of the roles:

aud

REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value. It MAY also contain identifiers for other audiences. In the general case, the aud value is an array of case sensitive strings. In the common special case when there is one audience, the aud value MAY be a single case sensitive string.

[Werner Keil]

On Wednesday, January 25, 2017 at 6:32:39 PM UTC+1, sst...@redhat.com wrote:

I think the minimum starting use case is that a user has a workflow that involves 2 or more micro services. They are using an IdP to produce a JWT that has a subject and workflow associated roles.

What they need is the ability to configure the micro services to:

1. accept that JWT is valid. This goes to defining acceptable signatures and encryption. A default implementation of a javax.security.auth.message.module.ServerAuthModule that illustrates this would be needed for a compatibility test.

2. Some security configuration definition that allows for the mapping of the subject and workflow roles into the security domains of the containers hosting the micro services.

Sounds like a perfect use case to "eat our own dogfood" if at least a first working draft of a configuration API was also available ;-)

Eclipse demonstrates how such things are reusable e.g. the Preferences API and many others.

There's no real difference between running them in an IDE or desktop and a service, especially if services become smaller or "containers" are nothing more than big or small runnable JARs.
 

[John Clingan]

I replied in the MicroProfile 1.1 thread about setting up a security committee and a security lead (at least for this particular effort). That's what I get for reading email in the wrong order :-)

Even with the revival of this thread, I think its good to follow the proposal I outlined in this thread. I'm always open to feedback, of course.

[stho...@redhat.com]

Most services themselves won't have to deal with OIDC directly as they don't need to obtain the tokens themselves. Although, some services will need to when they act on behalf of themselves rather than on behalf of the user. That would probably be beyond the scope of this spec, but I would still point towards OIDC as a recommendation on how to obtain tokens.

The ID token outline in OpenID Connect is there for authentication purposes and as such the standard fields are all there to establish identity.

The access token from OAuth2 is what should be used to access a protected resource. The problem with the access token is that there is no standard for it. It's just a piece of string. JWT has become a defacto standard and most IdPs issue JWTs as the access token.

Now the problem with JWT is that there are very few fields defined. These are primarily there to verify the validity of the token and not the permissions of the user.

For plain RBAC the primary thing that is missing from JWT is roles. There's just no standard way to add that to a JWT. If you come up with some way it won't work for all IdPs. Most likely the only IdPs that would be possible to use is those where you can configure the claims that goes into a token. Some let you do that others don't.

My recommendation would be:

* Recommend using an OIDC IdP to obtain tokens

* Use/create a library to verify the JWTs. Check signature, iss, aud, exp and nbf (if present) to verify the token is valid

* For RBAC allow a pluggable mechanism to extract/retrieve roles given a token. Some may extract it from a claim in the token others from a database/service

* Allow for services to implement authz however they want

* As an extension consider UMA

[Alasdair Nottingham]

Hi,

I think we should start by identifying the key scenarios we want to support, and then work towards the right solutions. As you say many micro services wont need to use OIDC directly, but many (most?) will need to be able to receive information. This aren’t expressed in the right way, so feel free to pick apart, but I think these might be things people need to do, but whether we address all, or a subset should be discussed.

* Service A calls service B sending service identity.

* Service A calls service B sending user identity.

* Service A calls service B sending user identity + authorization info

* Service A calls service B sending service identity + authorization info

* Service A calls service B sending service identity, and end user identity + authorization info.

* Service A calls service B sending service identity + authorization info, and end user identity.

* Service A calls service B sending service identity + authorization info, and end user identity + authorization info.

I’m being a little careful around the term authorization info. In prior discussions this was suggested to be the ‘roles’, however my understanding of RBAC led me to believe that different micro services would use different role names, based on what has meaning in the context of that service. As such it is possible that the roles in service A have no meaning in B, or even worse the same role name exists in both, but a holder of the role in service A does not imply that user should have access to things in service B protected by that role.

My understanding of RBAC might be incorrect, or limited, but it seems to me that if a role name is expected to have meaning between services that creates a coupling between the two that would seem to me to be undesirable in the context of loosely coupled distributed micro services.

Alasdair

--
You received this message because you are subscribed to the Google Groups "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.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/60a11257-97d5-45be-9332-4142345ebf7a%40googlegroups.com.

[sst...@redhat.com]

So we could attempt to define how role information should be included in the JWT as well as provide a JWTCallback implements javax.security.auth.callback.Callback and and JWTPrincialCallback which would be similar in functionality to the javax.security.auth.message.callback.CallerPrincipalCallback (javadoc). A JWTGroupPrincipalCallback would be similar in functionality to the  javax.security.auth.message.callback.GroupPrincipalCallback (javadoc).

A ServerAuthModule would then obtain the caller identity and mapped roles doing something like:

public class JWTAuthModule implements ServerAuthModule {
    protected CallbackHandler callbackHandler = null;

    public AuthStatus validateRequest(MessageInfo messageInfo, Subject clientSubject,
                                      Subject serviceSubject) throws AuthException {

        try {
            // Get the JWT token
            JWTCallback jwtCallback = new JWTCallback(messageInfo);
            this.callbackHandler.handle(new Callback[]{jwtCallback});
            JWTToken token = jwtCallback.getToken();

            // Associate caller principal identity represented by the token with the clientSubject
            JWTPrincipalCallback principalCallback = new JWTPrincipalCallback(clientSubject, token);
            // Associate the caller roles with the clientSubject
            JWTGroupPrincipalCallback groupCallback = new JWTGroupPrincipalCallback(clientSubject, token);
            this.callbackHandler.handle(new Callback[]{principalCallback, groupCallback});

            // the mapped caller identify
            Set<? extends java.security.Principal> caller = clientSubject.getPrincipals(JWTPrincipal.class);
            // the mapped caller roles
            Set<? extends Group> roles = clientSubject.getPrincipals(JWTGroup.class);

        } catch (Exception e) {

        }
        
    }

[sst...@redhat.com]

It would be the deployer of the service endpoint that identified the roles they required an invocation to have is what I would expect.

The configuration problem is then how to map from the OIDC generated JWT token to associated roles in each service endpoint domain. The current state of affairs requires that you configure/integrate each service endpoint to perform this mapping.

For this effort, it would seem to be a benefit if we could work on how one might standardize role grants on a service basis in the JWT, perhaps using the aud field. If the authentication layer could generate a roles objects that includes the grants for each service along the lines of:

aud: [client_id;serviceA:role1,role2;servieB:roleB1,roleB2;...]

in such a way that validation of the token validates the role grants, that would be nice. How to achieve this is the question.

[stho...@redhat.com]

On Saturday, January 28, 2017 at 1:28:27 AM UTC+1, Alasdair Nottingham wrote:

Hi,

I think we should start by identifying the key scenarios we want to support, and then work towards the right solutions. As you say many micro services wont need to use OIDC directly, but many (most?) will need to be able to receive information. This aren’t expressed in the right way, so feel free to pick apart, but I think these might be things people need to do, but whether we address all, or a subset should be discussed.

* Service A calls service B sending service identity.

* Service A calls service B sending user identity.

* Service A calls service B sending user identity + authorization info

* Service A calls service B sending service identity + authorization info

* Service A calls service B sending service identity, and end user identity + authorization info.

* Service A calls service B sending service identity + authorization info, and end user identity.

* Service A calls service B sending service identity + authorization info, and end user identity + authorization info.

I would go for only two scenarios at least initially:

* Service A invokes Service B on behalf of someone else - in this case Service A propagates the incoming access token

* Service A invokes Service B on behalf itself - in this case Service A should obtain an access token through Client Credentials Grant

It's up to Service B to decide if the given access token should be permitted or not. There are a few ways to do that:

* Based on subject alone and some internal permission system in the service

* Based on a claim that can be mapped on to a role within Service B

* Using UMA

Given the need to support different IdPs you're just not going to be able to define a common JWT format where there is a given claim that encodes roles. Even with that you're still left with the problem that "roles" defined in the token may have to be mapped onto internal roles for the service.

[stho...@redhat.com]

I really doubt that prescribing some standard way of encapsulating "roles" into the token will work. Not all IdPs even have the concept of roles. Take for instance tokens obtained from Google logins.

Using an existing claim like 'aud' would be even more difficult as it's intended to be just a list of client_ids, nothing more. At least with Keycloak it would be easier to add a new claim than to change a built-in claim like aud. I'd imagine others do the same as there are some smarts needed for the aud claim (i.e. add all clients in a specific group of clients).

[Werner Keil]

I replied in the 1.1 thread earlier.

Since Mark Little among others stated, security was important, and even though it may not cover more than a piece of larger security frameworks (Spring Security, PicketLink,...) could both the security lead and most committers be actual Eclipse committers, aka https://projects.eclipse.org/projects/technology.microprofile/who or others who know they are valid Eclipse committers ? (e.g. because they commit to other projects)

Every repository in https://github.com/microprofile has between 70 and 90% code by people who either are no Eclipse committers at all or whose paperwork is still pending. Hence their contributions are stuck and won't qualify for a release any time soon. E.g. for https://github.com/microprofile/microprofile-samples/graphs/contributors only Ken and Martijn are committer members of Microprofile. I proposed a PR to fix the naming conventions and license header (I am Eclipse committer, not voted or asked to join MP, but I am allowed to contribute and merging my PR would be safe also from an IP perspective)

Even if there was a large portion of code based on something else, shouldn't now, that the project is accepted and hosted by Eclipse every new green field repository start under https://github.com/eclipse with "microprofile-"?

There are dozens of good examples, e.g. Che https://github.com/search?q=org%3Aeclipse+che got 8 repositories now, including Docker files (who knows, maybe something Microprofile could some day also use?;-)

It matters less if this was called "microprofile-security", "microprofile-jwt" or bundled under something like "microprofile-incubator" or "microprofile-concept" or whatever, just do it and create it in the right place.
Otherwise the IP team will not even be done before Christmas wit 1.0, not to mention anything beyond that;-/

Werner

[sst...@redhat.com]

John Clingan is going to be starting a discussion on how to get the transition to Eclipse finalized today, and yes, anything new should be under the Eclipse foundation repo. If this cannot be done in short order, we'll see about creating project here an only accepting PRs from ECA signers. Is there a simple rest api for validating an ECA signer status? I know you can see the status from your landing page at accounts.eclipse.org without being logged in, for example mine:

https://accounts.eclipse.org/users/sstark88g

[sst...@redhat.com]

Ok, let's work on an example of a custom JWT roles field using key cloak at the basis for a more detailed discussion. I'll post a project link once I have something.

[Wayne Beaton]

I believe that we do have a public REST API for validating that somebody has an ECA (or is a committer), but I'm waiting on confirmation from the Eclipse webdev team.

I'm  curious to learn a bit more about what you're thinking. This may be a good experiment to move us forward with having an "Eclipse MicroProfile" organization on GitHub.

We can move this discussion to a different channel if you'd like.

Wayne

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/bc572d5c-2524-419f-b409-349b0a912ce9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation

[Werner Keil]

Technically it for Identity resolution, I think it may be a good place here, but everything else especially checking your own (or somebody else, e.g. an employee of a member company) ECA and committer status could better fit here https://groups.google.com/forum/?hl=de#!topic/microprofile/mAdS7J1IR4o

Or in a new thread.

> If you cannot get the contributor to sign an ECA, you have to find another solution.

is also important to capture, because quite a few cases look like "My buddy in this other project told me about this, so I list him as an @author to give him credit" and some involved in some of these discussions do not seem to fully understand either they and every "buddy" have to sign at least the ECA (or some become a committer, so they can push to the "Eclipse Microprofile" repositories themselves) 

I hope this helps a bit to get a better understanding of what needs to be done to contribute code to the official future repos.

Thanks,

Werner

[sst...@redhat.com]

I have moved this discussion to:

https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/microprofile/V5m4IvG7Ml8/Na3uOW-tDAAJ

On Monday, January 30, 2017 at 1:37:14 PM UTC-8, Wayne Beaton wrote:

I believe that we do have a public REST API for validating that somebody has an ECA (or is a committer), but I'm waiting on confirmation from the Eclipse webdev team.

I'm  curious to learn a bit more about what you're thinking. This may be a good experiment to move us forward with having an "Eclipse MicroProfile" organization on GitHub.

We can move this discussion to a different channel if you'd like.

Wayne

On 30/01/17 01:58 PM, sst...@redhat.com wrote:

John Clingan is going to be starting a discussion on how to get the transition to Eclipse finalized today, and yes, anything new should be under the Eclipse foundation repo. If this cannot be done in short order, we'll see about creating project here an only accepting PRs from ECA signers. Is there a simple rest api for validating an ECA signer status? I know you can see the status from your landing page at accounts.eclipse.org without being logged in, for example mine:

https://accounts.eclipse.org/users/sstark88g

[Werner Keil]

Thanks.

About CDI or JavaEE integration, I can tell from several real life use cases, that baking in or mandating a "Full Java EE Context" or APIs that only work in a running EE container would be bad and significantly reduce the value of such security measures.

Almost every one of these need something like
@Security(username="foo", role="accounting"...)
or
@Permission(name="a" type="b"...)

Having to load the full enterprise context takes time and e.g. Integration Tests or others that must run in a full container therefore take much longer to run.
If you have certain tests where you don't need full access to a DB or external systems, but still need to run it with some aspects of security e.g. a certain role or user, doing that in an "SE" or "Fat JAR" like environment is crucial and increases test performance among other values (e.g. those who need to run that within a Rich Client could also do that)

There are myriads of alternatives for configuration, so should a configuration API run only in a full Java EE context, it would be sad, but certain tests or applications have other options (e.g. Eclipse Preferences, OSGi)
For security the only alternatives currently are vendor-specific (Spring Security, etc.) or completely home-made for a project and company.

Werner

[Werner Keil]

JWT or other security and identity protocols/standards to handle in a language-neutral way (also, but not only in Java) could be a good effort.

E.g. https://iot.eclipse.org/ also has a couple of projects that e.g. support the MQTT standard or others in Java and other languages like C, Node.js or Lua just to name a few.
If something like the Conference sample has an Angular or other .js frontend, then supporting both Java (on some nodes) and JavaScript, possibly other languages (maybe even C/C++ if you include IoT devices;-) becomes crucial.

[Boleslaw Dawidowicz]

I have discussed with Pedro and if there is a need for someone to lead security site of the discussion he can help. Unfortunately he totally overloaded right now and heading for PTO. He can engage more from 2nd March. 

Pedro has extensive EE security experience from his past PicketLink work. He is on JSR 375 EG. Implemented core features of both Elytron in EAP and Keycloak. He is also leading our Authorisation effort in Keycloak which is implementation of UMA (User Managed Access) spec - another extension of OAuth2)

In the menatime I can try to help although also away fully next week. 

We have number of good ideas and feedback in this thread. Key question is how we want to bring it closer to conclusion or to wrap up and pass for review round. 

I would suggest a simple google doc to write down key usecases and suggestions around solving them from this conversation. 

Thoughs?

[Werner Keil]

Sounds good to have someone with PicketLink background who is also involved in the JSR 375 EG participate or offer to take the lead.

I am among the most active JSR 375 EG members right now and know, there's a lot of momentum right now, so maybe for areas like OAuth, OpenID, JWT and other security concerns MicroProfile could use synergies with an already active standard here ;-)

Werner

[sst...@redhat.com]

I think we are drilling down to wanting a baseline JWT extension that supports:

- Have sufficient information to support the getPrincipal() call.
- Have sufficient information to support the isCallerInRole(...) call.
- Have a requirement for a RSA public key verification.

This along with some use cases should get a first draft of a spec proposal.