[Se-leg-ref] Kommentarer på uppdaterad dokumentation

Hej igen, Jag är lite osäker på hur du menar med symmetrisk vs. asymmetrisk i det här fallet. Som jag ser det så har vi bara tagit bort mellanhanden (användarens webbläsare), och inte vänt på flödet. Vi har valt att implementera ett flöde som så långt som möjligt följer det vanligaste OpenID Connect flödet. Detta har vi valt eftersom de inom den arbetsgruppen redan genomfört ett gediget säkerhetsarbete (som dessutom förbättrats efter att externa forskargrupper studerat protokollet närmare). Förutom säkerhet är det som tidigare nämnts en fråga av att försöka få en så standardiserad lösning som möjligt. Jag förstår er synpunkt om att vilja undvika en server för RP’n, men samtidigt ser jag inte hur det är möjligt att ta bort användandet av redirect_uri utan att göra ett stort avsteg från OIDC och hamna i en helt custom lösning. Vänliga hälsningar, --- Rebecka Gulliksson ICT Services and System Development (ITS) Umeå University SE-901 87 Umeå, Sweden rebecka.gulliksson at umu.se www.its.umu.se *From: *se-leg-ref <se-leg-ref-bounces at lists.sunet.se> on behalf of Magnus Hoflin <magnus at diglias.com> *Date: *Friday 30 September 2016 13:38 *To: *"se-leg-ref at lists.sunet.se" <se-leg-ref at lists.sunet.se> *Subject: *Re: [Se-leg-ref] Kommentarer på uppdaterad dokumentation Hej igen, Johan/Rebecka: bra kommentar att identifieringen kanske dröjer och att det är anledningen att ni har valt att göra som ni gör. Att OIDC är asynkront, och att HTTP är synkront, och hur de mappas till varandra är vi naturligtvis på det klara med. Men på en högre nivå är OIDC normalt ändå "symmetriskt". Problemet som vi ser det är att ni i steg 14 vänder på det och låter OPn agera HTTP-requestor, och gör lösningen asymmetrisk, och att det är någonting man vill undvika i den här typen av lösningar. Enklare lösningar som är symmetriska är enklare att följa, bygga och underhålla, det är därför vi fortsätter argumentera. Bifogat finns ett förslag på en sån symmetrisk lösning, som bara är ett par justeringar på ert förslag. Kontentan är att i valet mellan: - att undvika pollning RP->OP och - att undvika att öppna upp en server hos RPn så väljer vi att undvika att öppna upp en server hos RPn, alla dar i veckan. Men det vore förstås intressant att höra vad de andra IdPerna säger? (Och som sagt tidigare, vi anser att vårt förslag i allra högsta grad är i linje med specen. Vi kan argumentera mer för det om ni vill.) Mvh /Anders och Magnus