Trimming in the hopes of ending this thread someday. :) If I missed
something you consider important, please bring it back!
On Tue, Sep 1, 2015 at 3:25 PM, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:
>
> Yes. I think fetching FederatedCredential objects indexed by provider will
> not encourage the use of standards by IdPs it will just entrench the
> existing super-providers.
>
It will also enable sites that really do only accept a particular set of
trusted providers to do so. For better or worse, I think it's difficult to
suggest to every RP that their options are "In-DOM NASCAR" on the one hand,
and "every OpenID Connect-supporting origin" on the other. I think it's
reasonable to put more trust in an origin like `accounts.google.com` than
in `mikewest.org`, and I think it's reasonable to allow RPs to do so.
> 1. Bob logs in at IdP site, SecureIdP
> 2. SecureIdP stores a FederatedCredential for each protocol it supports
> (indexed by some protocol identifier).
> 3. Bob logs in at IdP site, OtherIdP
> 4. OtherIdP stores a FederatedCredential for each protocol it supports
> (indexed by some protocol identifier).
> 3. User visits RP site, SomeService, that supports login via protocols A,
> B and C (in order of preference).
> 4. RP site calls API.get({"protocols":["A","B","C"]});
> 5. User is prompted with account chooser dialogue:
>
> RP site supports federated login.
> Do you want to login with one of the following accounts:
> 1. Account: Bob
> Provider: SecureIdP
> Protocol: A
> 2. Account: The Bobster
> Provider: OtherIdP
> Protocol: C
>
> 6. User selects one of these and the credential object is returned to
> SomeService and that kicks of the appropriate auth protocol using that
> credential.
>
This flow makes sense, except insofar as it overloads the term
`FederatedCredential` to mean both "The hint that's given to an RP about
the way a user has chosen to sign into their site in the past." and "The
assertion from an IDP that it may be used as an IDP."
Perhaps this latter thing could be a flag on the `PasswordCredential`
saying "The origin to which this credential is bound supports protocols X,
Y, and Z." That would retain the mental model currently in the spec, and
make the flow simpler:
1. Bob signs into IDP.com.
2. IDP calls `navigator.credentials.store(new PasswordCredential({ id:
'Bob', password: 'hunter2', protocols: ['X', 'Y', 'Z'] }));`
3. Bob accepts the user agent's kind offer to store this credential for him.
Then:
4. Bob visits every-idp.com.
5. every-idp.com calls `navigator.credentials.get({ 'federated': {
'protocols': [ 'X' ] } } )`
6. The UA helpfully offers Bob IDP.com.
Or:
7. Bob vists not-every-idp.com
8. not-every-idp.com calls `navigator.credentials.get({ 'federated': {
'providers': [ 'https://accounts.google.com' ] } } )`
9. The UA can't help Bob, because he doesn't have a Google account, the
poor guy. :(
WDYT?
-mike