Some additional review...
Big question: how much to do with ABFAB does this really have, vs.
essentially any really usable client UI for a non-trivial GSS-API
mechanism? More to the point, is this open to contributions from other
perspectives to broaden the document's applicability? I got the sense that
other than mentioning an NAI a fair bit, there's not much specific to
ABFAB here.
Section 3:
Is the trust anchor about verifying a service, or about verifying the
authentication service (avoiding the "IdP" term, but you know what I
mean)? I thought the latter, and that service verification was a
by-product of ABFAB being a mutual-auth mech. Think this text could be
clearer if so.
Section 4:
Starts awkwardly. Suggest excising the first clause ("When using the ABFAB
architecture to perform federated authentication to some service,")
It specifically says you're not trying to recommend the use of "identity
selector" as a term, but the document sure focuses on that term. Is there
a good reason not to recommend that? Or are you talking mostly about how a
user would perceive it? Still seems like unifying that makes sense; the
web is helped by the fact that the thing you use to access it is "a
browser".
Section 6.3
I suggest reconsidering the use of "provisioning" here. It's a
well-understood term, even in this exact context of provisioning, say,
wireless authentication info, into clients. I think it's fine to use it.
Section 6.3.2:
Implies a free lunch: "In this case, trust anchors could be directly
provided through the provisioning mechanism to help establish the trust
relationship in a secure manner."
If there were actually any way to do that, you'd already have the trust
anchors. This just moves the problem to a different set of trust anchors.
Section 6.3.3:
I can't really see the norm being auto-provisioning the password itself
into clients. I would think it much more likely the password would be left
out of that step and the user would enter it then or later, so there's no
confusion likely. Maybe this is tied up with the need for a way to verify
identities provisioned into the selector.
Section 6.5:
Is it really impossible to verify identities somehow? Authentication at
least should be verifiable; it certainly would be with other federated
mechanisms.
Section 7:
Delving firmly into opinion, consider that familiar apps like mail and IM
clients all feature the multiple account dialog these days. On the one
hand, it seems like success depends on an ABFAB "identity" being yet
another account option in those apps. Maybe that needs some discussion. If
it's not possible to hope for this, why not? And why shouldn't that raise
red flags for me as a reader? How has this worked or not worked for, say,
Kerberos? Can we learn anything from that?
-- Scott
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
