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
To make it very explicit: the goal is to enable mediasuite.clariah.nl to work directly with AnnoRepo, so no import/export is required between the MS and AnnoRepo (which would be very useful for other applications as well).
One thing that stands in the way currently is that AnnoRepo only seems to support individual users:
users can get an API key
users can CRUD their own annotations
users can give other users access to annotations (or just via annotation containers only?)
This should be fine for individual users, but not for applications that should be able to create annotations on behalf of (known, logged in) users, e.g. in the following way:
application can get an API key
application can CRUD annotations on behalf of user (annotation will then be OWNED by user)
for each call the application should send the OpenID access_token of the user
AnnoRepo checks the access_token with SATOSA (is the user logged in)
I guess the consequence is that AnnoRepo either grants a:
API key for user (and simply ties that key to a AnnoRepo user)
API key for an application (and expects each request to include the API key + an OpenID access_token
A consequence of this is:
MS user x created a bunch of annotations
MS user x now wants to work directly with AnnoRepo to do some sort of analysis
When requesting an API key, the user must first login using SATOSA, so AnnoRepo can figure out for which user the API key is for.
So when considering this, it seems to make sense to have:
a CLARIAH user gets an API key tied to their SSO ID (by logging into SATOSA first); however AnnoRepo does not expect an access_token, since users won't implement this (e.g. in their Jupyter notebooks)
a "homeless user" gets a "simple" API key (no access_token expected)
an applications gets an API key (AnnoRepo always expects an access_token in the payload)
Ok these are some first thoughts on how this could work.
Note that: the Media Suite has implemented the so-called Authorization code flow, using the aforementioned access_tokens (and btw refresh_tokens), that enables applications to call APIs on behalf of a user.
The text was updated successfully, but these errors were encountered:
To make it very explicit: the goal is to enable mediasuite.clariah.nl to work directly with AnnoRepo, so no import/export is required between the MS and AnnoRepo (which would be very useful for other applications as well).
One thing that stands in the way currently is that AnnoRepo only seems to support individual users:
This should be fine for individual users, but not for applications that should be able to create annotations on behalf of (known, logged in) users, e.g. in the following way:
access_token
of the useraccess_token
with SATOSA (is the user logged in)I guess the consequence is that AnnoRepo either grants a:
access_token
A consequence of this is:
So when considering this, it seems to make sense to have:
access_token
, since users won't implement this (e.g. in their Jupyter notebooks)access_token
expected)access_token
in the payload)Ok these are some first thoughts on how this could work.
Note that: the Media Suite has implemented the so-called Authorization code flow, using the aforementioned
access_token
s (and btwrefresh_token
s), that enables applications to call APIs on behalf of a user.The text was updated successfully, but these errors were encountered: