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).