[OCM] Re: Token exchange is missing third party token validation

[Giuseppe Lo Presti <[e-mail]>]

I fully agree this is a 'noble' intent, and at least it would grant an 
appendix.

Your idea of writing separate I-D documents may make sense here. At the 
same time, the main I-D could still include a recommendation when a 
given kind of integration is to be achieved, with reference to the 
separate document (or the appendix), but again not a prescription IMHO.

I must say that I didn't like too much our model of a server-side shared 
secret, but it has its value now that you explain that a JWT would need 
to become quite large (with potential side effects) to be effective.

Do you want to start with an appendix for now, or go with a new document 
right away?

Cheers,
Giuseppe



On 18.05.2026 09:11, Micke Nordin wrote:
> I have started implementation on the Jupyterhub side now, and I can 
> tell you that the integration will need more information than what is 
> currently in the JWT, no matter what. Essentially the webapp server 
> needs to know the entire payload of the share (minus possibly the 
> sharedSecret).
>
> So it doesn't matter as much as I thought whether the token is a JWT 
> or an opaque string. I still need to establish a back channel between 
> the sending server and the webapp server anyway, unless we stuff a lot 
> more information into the JWT.
>
> My point with this PR is to make it easy to write integrations that 
> will work for any OCM server, so you only need to support the generic 
> webapp protocol on the OCM server, and add all of the specifics of the 
> integration on the webapp server side.
>
> This proposal does not achieve that goal, but I still think it is a 
> noble goal that we should try to achieve, just because I see alot of 
> potential in the webapp protocol, and it would be a shame to have alot 
> of bespoke integrations out there, that needs custom integration code 
> on the OCM side.
>
> Essentially we have three options:
>
> 1. we put a lot of data into the JWT, more or less the entire share 
> payload, or
> 2. we have an introspection endpoint on the OCM server.
> 3. we establish an api endpoint on the webapp server that gets a 
> separate POST with information at the share time, that can be related 
> to the JWT via the client_id.
>
> I can see use cases for each of these, and maybe the best thing we 
> could do is write a separate specification for OCM integrations, and 
> keep the opaque string as the wording in the core spec.
>
> That way, you would know what to do if you want to write an 
> interoperable integration, and if you only want to recieve webapp 
> shares, you donyhave to care what the token looks like or anything else.
>
> All the best,
> Micke
>
>
> Den 18 maj 2026 08:18:02 CEST, Giuseppe Lo Presti 
> <Giuseppe.LoPresti=[e-mail]> skrev:
>
>     Hi Micke, all, Coming back to this thread a bit late. I have an
>     "academic" question here, prior to approving/changing the proposed
>     PR [1]: with all good intentions and the added interoperability,
>     do we want that the OCM spec prescribes something that is the
>     internal business of a provider and has no direct impact on the
>     protocol between providers? Or shall we just recommend it? Maybe
>     the chairs may suggest what the typical approach within IETF is -
>     is it preferred to specify more, or should we target the minimal
>     level to ensure interoperability? My case for why I'd leave it as
>     a recommendation would be as follows, starting from the example:
>
>         The proposal is meant to increase interoperability by not
>         requiring extra machinery, that is implementation specific.
>         When doing a webapp share, the sending server sends a share
>         notification to the receiving server. Now the user that
>         received the share wants to access the webapp. The receiving
>         server then exchanges the sharedSecret for a short lived
>         access token and posts the access token into an iframe served
>         by a third party, in this case a JupyterHub server operated by
>         the same folks that operate the sending OCM server. This
>         access token is ment to grant access to the webapp resource,
>         and so the webapp server needs to verify the token. 
>
>     Because it's a "server operated by the same folks", one could
>     imagine that the app server uses an internal trust relationship
>     with the OCM server (that is the EFSS server), in such a way that
>     the token shipped into the iframe does not need additional
>     verification. Our Collabora integration works pretty much like
>     that, in the sense that it only allows connections from our WOPI
>     servers, which in turn are in a trust relationship via shared key
>     with our EFSS servers. Moreover, as you suggested the token
>     exchange is performed by the EFSS server anyway, not by the webapp
>     server, and this makes perfect sense in terms of separation of
>     concerns. But precisely that allows more freedom for such a case.
>     Cheers, Giuseppe [1] https://github.com/cs3org/OCM-API/pull/365 On
>     07.05.2026 16:51, Micke Nordin wrote:
>
>         Sorry! I accendently replied only to Mathias, here is my reply
>         to all!
>         ------------------------------------------------------------------------
>         Hello! On 5/7/26 2:47 PM, Matthias Kraus wrote:
>
>             Hi, I would make sure the token is opaque to Receiving
>             Servers. What it contains is up to the SendingServer
>             Implementation, so the SendingServer is free to use
>             anything, e.g. a JWT, to allow its Services to
>             authenticate it. 
>
>         The point of the proposal is that anyone with access to the
>         token, including third parties, should be able to verify that
>         the token was issued by the sending server by checking the
>         signature against the sending servers public key.
>
>             Then it's a implementation detail when the webapp service
>             is configured to send tokens it gets to some (oidc?)
>             authentication service or to validate the JWT. That way we
>             minimize complexity across Implementations which would
>             harm compatibility. 
>
>         The proposal is meant to increase interoperability by not
>         requiring extra machinery, that is implementation specific.
>         When doing a webapp share, the sending server sends a share
>         notification to the receiving server. Now the user that
>         received the share wants to access the webapp. The receiving
>         server then exchanges the sharedSecret for a short lived
>         access token and posts the access token into an iframe served
>         by a third party, in this case a JupyterHub server operated by
>         the same folks that operate the sending OCM server. This
>         access token is ment to grant access to the webapp resource,
>         and so the webapp server needs to verify the token. If we
>         don't want to specify the format of the token, then it will be
>         hard to implement the integration with the webapp server. You
>         would need a token introspection endpoint or you could use a
>         JWT, with out specifying how it is supposed to be done,
>         leading to alot of similar, but slightly different
>         implementations. Siince this is a flow that will need to be
>         implemented in every single webapp server, I think it makes
>         sense to specify it.
>
>             I haven't implemented the token flow so far, so tell me if
>             I've missed something. 
>
>         When implementing this in Nextcloud and what Mahdi did in
>         reva, we both ended up with almost the exact same solution
>         (but not exactly the same), which tells me that this is the
>         way to go, and in the interest of interoperability, we should
>         be explicity on how to do it. It is not complex to do, and
>         making everyone figure it out on their own, without the
>         possibility to re use integrations across different vendors is
>         not good (i.e. Nextcloud would need a different Jupyterhub
>         integration on the Jupyter side, than what Opencloud what
>         need, and that would be different from what ownCloud would
>         need). We can write OCM integration could for many different
>         webapps, that could then be reused by all OCM servers, which I
>         think is powerful, at the cost of making everyone write twenty
>         lines of JWT code.
>
>             Best, Matthias 
>
>         All the best, Micke
>
>             Am 6. Mai 2026 01:20:34 GMT-06:00 schrieb Micke Nordin
>             <kano=[e-mail]>: In the so called "code
>             flow" we specify a /token endpoint where you can exchange
>             a sharedSecret for an opaque access token in the vain of
>             OAUTH 2. Now that we are starting to work on webapp
>             sharing, I notice that we are missing the ability for
>             third parties to validate an issued access token. User X
>             on Server A shares a webapp with User Y on Server B.
>             Server B exchanges the sharedSecret for an access_token at
>             Server A's token endpoint and posts this access_token into
>             the webapp servers iframe. The webapp server of Server A
>             is in this case not the OCM server itself, but rather a
>             third party such as Jupyterhub or a wopi server. Now the
>             webapp server needs to validate the access_token with
>             Server A, but now with the current spec, we are stuck.
>             There are two ways to solve this: 1. We introduce a token
>             introspection endpoint:
>             https://www.oauth.com/oauth2-servers/token-introspection-endpoint/
>             2. We use JWT profile for OAUTH access tokens
>             https://datatracker.ietf.org/doc/html/rfc9068 Both of
>             these have some drawbacks: 1. The introspection endpoint
>             needs either be autheticated with basic auth, or hidden
>             behind access lists. 2. If we go the JWT route, the token
>             is no longer opaque. To me it seems like using JWTs with
>             content we can examine and verify signatures on are the
>             simplest to implement and makes most sense to me. We
>             already require servers that use the code flow to sign
>             requests using http-sig so the key material we need is
>             already there, so we only need to change the spec to
>             specify the structure of the JWT access_token. Whats do
>             you think? All the best, Micke
>             ------------------------------------------------------------------------
>             OCM mailing list [e-mail] To unsubscribe send an
>             email [e-mail] 
>
>         ------------------------------------------------------------------------
>         OCM mailing list -- [e-mail] To unsubscribe send an email
>         to [e-mail] 
>
>     ------------------------------------------------------------------------
>     OCM mailing list -- [e-mail] To unsubscribe send an email to
>     [e-mail]
>
>
> _______________________________________________
> OCM mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]