Yadis

Yadis er en netværksprotokol til at opdage OpenID , OAuth og XDI-tjenester ved hjælp af Yadis ID. Oprindeligt designet til at opdage digitale identitetstjenester, kan Yadis nemt også bruges til andre tjenester.

Yadis-id'et kan være en normal URL eller det nyere XRI i-name , hvor i-navnet skal opløses i URL'en. Den såkaldte Yadis URL er enten Yadis ID (hvis det er en URL) eller den løste URL fra i-navnet.

Derudover specificerer Yadis, hvordan Yadis URL'en skal bruges til at få styr på en tjeneste, kaldet Yadis Service Descriptor . Denne beskrivelse følger XRDS -formatet og samler flere autorisations- og godkendelsestjenester i en Yadis URL. Tjenestebeskrivelser kan have parametre.

Modulær arkitektur

Yadis følger REST -paradigmet , som er veletableret inden for webudvikling. Baseret på antagelsen om, at identifikatorer kan adresseres via en URL eller andre identifikatorer (såsom i-names XRI ), der kan løses i en URL, knytter Yadis et XRDS-dokument (et XML -format, der beskriver muligheder) til hver URL, der udtrykker den tilknyttede funktioner eller tjenester. Ejeren af Yadis ID'et kan vælge, hvilke tjenester han vil bruge i sit XRDS-dokument. Efter modtagelse af dokumentet kan den stolende part (for eksempel et websted, der accepterer en Yadis-id) vælge en passende tjeneste, såsom en protokol til godkendelse. Dette gør det muligt for eksisterende websteder, såsom blogs, nemt at implementere grundlæggende Yadis-funktionalitet, såsom at omdirigere besøgende til en blog til relevante oplysninger om blogejeren, samtidig med at mere komplekse applikationer kan bygges (f.eks. sende komplekse webstedsejerforespørgsler direkte til Yadis). -websted)

Yadis Service Descriptor Discovery

Dokumentet om de funktioner, der er forbundet med URL'er, er placeret på:

I en ikke-standard HTTP-header X-XRDS-Location,
I det tilsvarende metatag i HEAD-sektionen i et HTML-dokument <meta http-equiv="X-XRDS-Location" content="http://example.com/yadis.xml">,
eller givet, når der anmodes om en speciel MIME -type application/xrds+xmli en GET-anmodning til en identifikator-URL.

Udviklere kan vælge, hvad der skal implementeres baseret på forskellige faktorer, såsom om serversiden af identifikatoren kan tilgås.

XRDS-dokumenter

Her er et eksempel på XRDS- kapacitetsdokument:

<?xml version="1.0" encoding="UTF-8"?> <xrds:XRDS xmlns:xrds= "xri://$xrds" xmlns= "xri://$xrd*($v*2.0)" xmlns:openid= "http://openid.net/xmlns/1.0" > <XRD> <Service priority= "50" > <Type> http://openid.net/signon/1.0 </Type> <URI> http://www.myopenid.com/server </URI> <openid:Delegate> http://smoker.myopenid.com/ </openid:Delegate> </Service> <Service priority= "10" > <Type > http://openid.net/signon/1.0 </Type> <URI> http://www.livejournal.com/openid/server.bml </URI> <openid:Delegate> http://www.livejournal. .com/users/frank/ </openid:Delegate> </Service> <Service priority= "20" > <Type> http://lid.netmesh.org/sso/2.0 </Type> <URI> http: //mylid.net/liddemouser </URI> </Service> <Service> <Type> http://lid.netmesh.org/sso/1.0 </Type> </Service> </XRD> </xrds: XRDS>

Et sådant XRDS- dokument, opnået for en given URL ved hjælp af en af ovenstående mekanismer, udtrykker følgende information:

Denne URL er Yadis identifikator URL.
Denne URL understøtter OpenID -protokollen gennem to servere og to delegerede.
Denne URL understøtter version 1.0 og version 2.0 af LID -protokollen ved hjælp af en delegeret.
For brugerlogin foretrækker URL-ejeren at bruge deres LiveJournal-konti og OpenID -protokollen (prioritet 10). Hvis dette ikke er muligt (f.eks. understøtter den stolende part ikke OpenID, eller LiveJournal-serveren er utilgængelig), vil ejeren gerne bruge LID -URL'en http://mylid.net/liddemouser (prioritet 20), eller MyOpenID-tjeneste (prioritet 50).

LID, OpenID og udviklerfællesskabet

Yadis blev foreslået af udviklerne af Light-Weight Identity (LID) og OpenID -protokollerne . Medlemmer af OASIS , XRI Technical Committee, har tilsluttet sig dette samarbejde .

Yadis er et åbent initiativ, så andre udviklere begynder at bruge XRDS- beskrivelser og udnytter muligheden for at vælge en balance mellem let implementering på den ene side og mængden af implementeret funktionalitet.

Se også