4:23 p.m.
Hej,
Tack för den uppdaterade dokumentationen,
https://github.com/SUNET/se-leg-docs/blob/master/oidc_flow.md, den har
underlättat mycket för förståelsen!
Vi har huvudsakligen två kommentarer:
Kommentar 1:
Det fattas en/två pilar direkt innan steg 14. Man kan ju inte skicka en
HTTP-response från ingenstans utan det måste ju initieras av en
HTTP-request. Att införa en HTTP-request skulle också lösa det problem vi
tidigare har lyft, nämligen att man inte vill ha en OP-initierad
backend-kanal till IdPn eftersom en sån kanal skulle bara ställa till med
FW-problem etc. Vi föreslår två nya steg precis innan steg 14, kalla dem
13.8 och 13.9:
- 13.8: Pil "User" -> "RP/IdP": Användaren indikerar mot IdPn
att
han/hon är klar med identifieringen på t.ex. biblioteket. Detta kan bl.a.
ske när användaren "klickar bort" QR-koden på mobilen.
- 13.9: Pil "RP/IdP" -> "OP": IdPn begär ett Authentication
response.
Kommentar 2:
Har vi förstått det rätt att det 'nonce' som IdPn genererar i steg 4 är
samma 'nonce' som också används som QR-kod? Hela den här processen kan
sägas baseras på en identifieringstransaktion som OPn ansvarar för. Vi
tycker det känns avigt att IdPn ska generera transaktionsIDt (idag
"noncet") för den transaktion som OPn ansvarar för. Vi förelår att *OPn*
genererar ett 'transaktionsID' som returneras i steg 5 och som sen används
i QR-koden. Detta transaktionsID skickas med i steg 13.8 och 13.9 ovan, så
att OPn vet vilken transaktion den ska returnera identiteten för. Detta är
möjligt p.g.a. att användaren är inloggad via steg 1-2.
Om man fortfarande vill använda ett nonce i det syfte specen anger, dvs som
skydd mot replay-attacker, så kan man förstås göra det också. Men
transaktionsIDt bör inte blandas ihop med replay-skydd-noncet.
Och om det är vi som har feltolkat flödet så är det nog bra om ni
uppdaterar så att det inte heter nonce på båda ställena.
Dessutom:
Om ni vill förtydliga ert sekvensdiagram ytterligare så vore det jättebra
ifall ni kopplade de olika stegen mot de steg som är listade i kapitel
3.1.1 i OpenID-specen.
Mvh
/Magnus och Anders, Diglias
--
Magnus Hoflin
Co-founder, CTO
+46 709-27 83 28
magnus at diglias.com
*Diglias*
J A Pripps gata 2
421 32 Västra Frölunda
www.diglias.com