On torsdag 29 september 2016 kl. 17:53:07 CEST Magnus Hoflin wrote:
Ja, den 302 som ni redan har listat som exempel på
steg 14 och som listas
som exempel i OIDC-specen.
Jag hänger inte riktigt med. Var någonstans står det att steg 14 är en 302?
Den kan ju inte skickas som ett
HTTP-response/redirect utan att den har föregåtts av HTTP-request.
Som vi har implementerat detta, helt och hållet i enlighet med OIDC-specen
enligt vad jag förstår, så är steg 14 en HTTP request från OP till RP.
Vi var nog lite otydliga. Vårt förslag baseras inte
mest på säkerhet,
snarare enkelhet och "spec-compliance".
Du har vid två tillfällen tagit upp detta som ett problem utifrån hur du vill
konfigurera dina brandväggar, att du inte vill tillåta inkommande connections
från OP till din RP. Nu säger du dock att det inte handlar om säkerhet utan
för att det ska "skulle göra se-leg-flödet lättare att förstå och lättare att
koppla till OIDC-specen". Vilket är problemet du försöker lösa egentligen?
Är det ett substantiellt problem eller lägger vi mer tid och kraft på den här
diskussionen än vad problemet egentligen rättfärdigar?
Jag kan inte säga att jag ännu har sett något som blir lättare eller bättre av
den föreslagna ändringen som jag tycker känns mest som ett försök att få
authentication flödet att se ut som att användarens webbläsare var inblandad,
när det i själva verket är en server hos er som är client och en server hos
se-leg som är server. Om jag förstår det rätt vill du dessutom tillföra några
out-of-band HTTP request/responses som inte alls finns med i OIDC-standarden,
vilket således leder till en svensk lösning snarare än en standardbaserad
lösning.
Jag vill dock öppet säga att jag inte har någon erfarenhet av just OIDC sedan
tidigare så jag hoppas att få höra fler röster i det här samtalet.
Trevlig kväll
/Fredrik