Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Clarify Application Registration Discovery

Aperta
  • Qualcosa non va?
#287 3 commenti 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Documentazione
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Ambito
documentation

Direzione di ricerca

Esamina le sezioni Authorization, Authorization Agent Discovery e Agent Registration Discovery della specifica insieme alle introduzioni su Application e Authorization Agent collegate nell'issue. Chiarisci come vengono individuati gli agent, come WebID e Client ID raggiungono l'Authorization Agent, quali sono i ruoli dei server e quale sia il rapporto tra Application e Data Registrations; il lavoro è completo quando questi punti sono coerenti nei documenti referenziati.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Recently, a number of questions came up on Gitter (gitter.im/solid/webid-profile, starting Oct 21 22:17) and in private conversation with @jeff-zucker, that make it clear to me the SAI text surounding the Application Registration Discovery is far from clear to a lot of readers. They pertain most importantly to the section on Authorization. I elborate here on them as to clarify things immediately to some of the readers, and leave it up to the panel how to do so in the documents.

A first crucial point might be overlooked because it is only mentioned in subsubsection after a whole lot of less crucial schema's and tables, while in fact it is the starting point of it al. The text is rather clear i.m.o., although concrete mention of "WebID" might provide easier hooks for readers:

The Authorization Agent for a given Social Agent can be discovered by de-referencing the identity [actually the identifier, e.g. the WebID] of that Social Agent, and extracting the object value of the interop:hasAuthorizationAgent statement from the Social Agent graph in the returned identity profile document [i.e. identity document, e.g. WebID Document].

In the application primer, this is quite clear:

Every user has an Authorization Agent which can be discovered from their WebID Document via interop:hasAuthorizationAgent predicate.

It was raised a number of types that this could/should also be a Link-header.

A second point of confusion centers around the myth that apps would need their own servers to use SAI. This is not true. The only servers involved in a SAI process are:

  • a Solid server on which the user's data is stored;
  • a Solid-OIDC server or other authentication server;
  • a server at which the app can discover its Application Registration;
  • a server at which the app can request (more) access to resources.

The last two roles are combined in the current SAI draft as the Authorization Agent. All servers are thus user-specific, not app-specific. An app only needs to find the AA in the user's WebID, and this AA points the app to its Registration in some user-side indexes. No need for the app to host anything. If the app needs more access, it redirects to the AA, who asks the user for approval, and updates the indexes accordingly.

This should be clear from the application primer (and is exactly why this document is separate from the AA primer), but might be more confusing in the full specification, since these aspects are treated alongside eachother there.

A third question is how the app should approach the AA. Both the specification's subsection and the application primer skip over this quite nonchalant. Neither actually specify how the WebID and Client ID are communicated to AA; that is to say, the reader is left to infer that from the example. Indeed, this is done by the standard authorization header used in Solid: an access token containing the WebID of the user and the ClientID of the application.

Finally, it occured to some that the Data Registrations would be copies of the actual data. This would, of course, make interoperability harder instead of easier, plus take a great deal more trouble. Luckily, this assumption is not true: the Application Registrations of two different apps contain pointers to the same Data Registrations (in as far as they can access the same data). So apps have (partly) their own discovery mechanisms, but always to the same data. The AA simply keeps the mapping from the App to the data it can access. Since Data Registrations are indeed often described in the specification within their role in app-specific discovery, it might be a good idea to clarify that they are indeed the same over the whole range of apps a user has.

Lingua principale
Bikeshed
Stelle
58
Fork
18
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di solid/data-interoperability-panel

Tutte le issue di solid/data-interoperability-panel

Issue simili

Altre issue su Documentation

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.