You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In https://datatracker.ietf.org/doc/draft-vandermeulen-oauth-resource-helper/ we thought a lot about "open" OAuth ecosystems. One of the things we researched but didn't spec in the end was how a client could discover the API of a resource server. Maybe OCM's discovery mechanisms can be repurposed for that? It's also very related to /.well-known/openid-configuration, but generalised for webdav-like APIs instead of just for identity.
client asks Resource Owner to type the FQDN of their EFSS
the client discovers details about the Resource Owner's EFSS (i.e. the Resource Server and Authorisation Server)
the client obtains access to a resource (share) using regular OAuth
the OAuth grant on the resource is then actually very close to an OCM share
the way API parameters are described could be copied from how we describe webdav endpoints etc in our discovery mechanism
It doesn't really change how OCM works, just reuses parts of its discovery mechanism. I might want to do some experimentation with this if I have time.
The text was updated successfully, but these errors were encountered:
In https://datatracker.ietf.org/doc/draft-vandermeulen-oauth-resource-helper/ we thought a lot about "open" OAuth ecosystems. One of the things we researched but didn't spec in the end was how a client could discover the API of a resource server. Maybe OCM's discovery mechanisms can be repurposed for that? It's also very related to
/.well-known/openid-configuration
, but generalised for webdav-like APIs instead of just for identity.It doesn't really change how OCM works, just reuses parts of its discovery mechanism. I might want to do some experimentation with this if I have time.
The text was updated successfully, but these errors were encountered: