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

[Micke Nordin <[e-mail]>]

I think I can try to write a standalone document for both the 
integration protocol, and for the federated groups over MLS, and we can 
decide if we want to fold it in or keep it separate. Parhaps it would be 
good to move big optional pieces of of the main document, just for 
readability.


/Micke

On 5/18/26 9:43 AM, Giuseppe Lo Presti wrote:
> 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]
>
> _______________________________________________
> OCM mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]