Ano, máš pravdu, že pro identifikaci a autentizaci mi stačí tohle. Jenomže Lojza si účet u IdP neudělá, protože nemá proč. Proč by zatahoval do věci další subjekt, který tam není potřeba? O tom je ten třetí zákon.

Prostředníka má smysl do toho zatahovat v okamžiku, kdy mi dá nějaké ověřené claimy, čímž zabrání např. vtipálkovi vyplnit registrační formulář e-shopu nesprávnými údaji, protože jeho adresa bude claimem, který IdP ověří.

Ale nehádej se tady se mnou a nepřesvědčuj mne. Naprogramuj to a přesvědč uživatele, aby to používali. Já ti jenom říkám, proč to nebude fungovat.

1. Drtivá většina webů, které používají Facebook login ho nepoužívá pro klasickou autentizaci, ale protože jsou s Facebookem relativně těsně propojeny a integrovány, bez něj by neměly moc smysl. Typický příklad: NetworkedBlogs

2. Řada webů (třeba i ty pornosity) ho používá kvůli dolování dat, dostanou se tak k relativně cenným údajům.

Facebook login, stejně jako Microsoft Passport zase trpí na centralizaci. Oba jsou proprietální systémy, které stojí a padají na ochotě těch subjektů je podporovat.

Jenomže to je v zásadě jakýkoliv systém s prostředníkem - třetí stranou. Možná ne proprietární, ale rozhodně závislý na ochotě IdP jimi být a zůstat. Jako relying party mám tedy na výběr ze dvou možností a obě jsou špatné.

Buďto budu akceptovat zcela jakéhokoliv IdP, čímž si zajistím nezávislost na konkrétním subjektu. Nemohu si ale být jist, jaké claimy mi budou schopni dát a jak budou zajištěné. Jedinou výhodou pak představuje, že si uživatel nemusí pamatovat další heslo. Ta je ovšem bohatě vyvážená komplikovanějším procesem přihlášení a registrace a nutností aby se uživatel *někde* nějak registroval a ideově souhlasil s tím, že tenhle účet třetí strany použije (idea, že si rozjede vlastního IdP je spíš teoretická). V takovém případě tedy třetí strana nemá fakticky smysl a porušuje třetí zákon.

Druhá možnost je, že potřebuji mít uživatele nějak "předověřené", potřebuju, aby mi IdP dal nějaké konkrétní claimy a nějak se za ně zaručil. V tom případě nicméně potřebuju jednoho nebo více konkrétních IdP, na nichž se tím stávám fakticky závislým (i když používám otevřenou technologii). Tady má ověřování třetí stranou smysl, ale přesto naráží na řadu netechnických problémů: Např. kde takového IdP vzít a nekrást? Zadarmo to asi dělat nebude a je ekonomicky rozumné mu za to platit? Pokud to bude IdP mít jako "přidruženou výrobu", hrozí konflikt zájmů. Pokud to bude dělat jako obživu, asi brzo zhyne.

Modelový příklad: provozuju e-shop a hodilo by se mi vědět, že uživatelem zadané jméno a adresa je skutečné, takže budu mít větší jistotu, že to není vtipálek, kterému pošlu dobírku, která se vrátí jako nedoručitelná a budu s tím mít akorát vydání. Tj. chci třetí stranu, která si (třeba zasláním dopisu) ověří, že adresa je skutečně funkční. Hodilo by se mi, kdybych mohl jako IdP použít třeba Aukro, které u svých uživatelů adresu korespondenčně ověřuje. Jenomže: bude Aukro skutečně chtít být IdP? Když tím bude pomáhat své konkurenci? Budu já chtít, aby Aukro vědělo, kdo jsou moji zákazníci? Budou se moji zákazníci chtít přihlašovat účtem třetí strany? Vyplatí se nějaké nezávislé třetí straně provozovat takovou službu?

Význam technologií, jako je SAML, je spíše v jiných oborech, v uzavřených nebo polouzavřených systémech. Např. abych já, jako ISV mohl dodat aplikaci, která snadno půjde zapojit do infrastruktury odběratele. Nebo pokud chci dělat nějakou federated identity, třeba umožnit do extranetu přístup partnerům a podobné věci. Proto je ostatně SAML tak složitý - předpokládá se, že požadovaného efektu dosáhnu nikoliv programováním, ale parametrizací, nějakým hotovým řešením. Že to bude problém "IT Pro" ne "Developer". Od toho tady jsou programy jako ADFS (Active Directory Federation Services od Microsoftu), již zmiňovaný Shibboleth (což je open source v rámci projektu Internet2), Athens (používaná v UK) nebo Tivoli (od IBM).

Pokládat některé aspekty za nedůležité je tvé svaté právo (já zase pokládám za nedůležité jiné aspekty, jako například jednoduchost technické implementace), je možné, že se všichni ostatní mýlí a ty máš pravdu, v tom případě tvůj systém bude úspěšný.

Že pokládáš za neřešitelné jiné aspekty je trochu zarážející, vezmeme-li v úvahu že jiné systémy je rutinně řeší, ale je jistě tvou volbou nestudovat stávající situaci v oboru, do kterého ses rozhodl vstoupit.

Prostě to naprogramuj a zveřejni a uvidíš. IMHO po tom pes neštěkne, ale budu rád, když se budu mýlit.

Myslím si, že hlavní rozpor mezi námi je v tom, že ty jako hlavní překážku rozšíření OpenID a podobných technologií vidíš obtížnou implementaci na straně SP a IdP a jako takovou se ji snažíš řešit. Já tento názor nesdílím. Myslím si, že pokud jediná výhoda, kterou tvůj systém nabídne, bude jednodušší implementace, nemá šanci na úspěch.

Problém spočívá ve třetím zákoně identity, tedy v tom, že do procesu autentizace by neměl být zatažen nikdo, kdo tam nezbytně nutně nepatří. Důvod neúspěchu první generace identity systémů (nejzářnějším případem je Passport, ale je jich spousta) je právě to, že lidé nechtějí do své komunikace zatahovat třetí stranu - ani z pozice koncového uživatele, ani z pozice SP. Pro velkou většinu aplikací je IdP jako třetí strana v podstatě zbytečný. Možnost být sám svým IdP je v tvém systému tak komplikovaná, že ji většina uživatelů nemá šanci využít. Smysl má IdP jako třetí strana v několika specifických případech, kde je ale obvykle vyžadována mnohem vyšší úroveň zabezpečení a kde není problém dostatečně robustní mechanismus implementovat.

Z mého pohledu jediným zajímavým momentem tvého návrhu je "slepé přihlášení". Z toho co jsi napsal nicméně předpokládám, že onen "jakýsi jednoznačný identifikátor tebou vybraného profilu" bude pro všechny SP stejný. Čímž se podle mého názoru výhoda anonymity dost ztrácí. Ono je dost jedno, jestli SP bude mít jako můj handle přímo moje ID nebo nějaký blábol, důležité je, aby se dva různí SP nemohli za mými zády domluvit a spojit si ta data. Mnohem rozumnější mi přijde implementace Personal Information Card, kde se jako identifikátor používá hash z PPID (jednoznačný identifikátor uživatele) a identity SP (podle certifikátu nebo hostname). To elegantně řeší soukromí i problém phishingu, protože každý SP dostane přímo technologicky jiný identifikátor. Viz čtvrdý zýkon identity - directed identities).

Další problém tvého řešení je, že IdP je z principu vždycky Auditing IdP, neumožňuje implementovat Nonauditing IdP. Jinými slovy, můj identity provider ví, kam všude se s ním přihlašuju (protože je tady přímá komunikace mezi ním a SP). Což pro tyhle jednoduché věci taky není dobře.

Další problém je v omezení volby IdP. Protože celá tahle záležitost není claim-based, mohu z pozice SP omezit přijímané IdP jenom na základě jejich doménového jména. Nemohu říct "beru jakéhokoliv providera, který mi sdělí tenhle claim".

Prostě mi přijde, že tvůj systém nenabízí oproti existujícím nic nového, kromě (možné) technologické jednoduchosti, ovšem výměnou za podporu jenom jediného scénáře.