[Openid-specs-fastfed] Feedback on Core spec

[Vittorio Bertocci]

Dear all,
We (OKTA|Auth0) are taking a deeper look at FastFed Core and wanted to
share some thoughts elicited by consulting the spec for prototyping.

*- 4.1.2.2 Endpoint discovery*
At the present moment, the way the specification is structured seems to
suggest that WebFinger is the primary mechanism implementers should
consider for discovery purposes. However it seems that in concrete
scenarios, SaaS type setups will likely to implement IDP or SP initiated
discovery flows where the operator is asked to enter a URL, vs the
relatively exotic WebFinger flow.
If the spec would be more explicit about IDP&SP initiated discovery flows,
perhaps mentioning them beforehand and giving them at least comparable
space to WebFinger, the spec might prove to be more readily usable as
implementation guide in a larger range of cases. At the moment the
impression that WebFinger is the primary discovery method is hard to avoid.

*- "destructive" handshake*
The fact that a repeated handshake will result in overriding everything
that changed since an earlier handshake can lead to unintended
consequences, if multiple changes occurred. Not all the changes might be
contextual to the reason for which a handshake was initiated, and applying
them can effectively lead to destructive side effects. It would be ideal if
handshakes could be more sophisticated- eg if I want to change attributes,
it would be great if I could just signal that without renegotiating the
entire range of settings currently under the purview of a full handshake.

*Protocol-specific language in the spec*
The current spec leans heavily on SAML for its samples- that might make it
hard for readers who aren't conversant in SAML to understand core concepts,
and in general might make it harder to discern what's SAML and that's
FastFed specific.
Using "pseudoprotocol" syntax, or presenting all samples in the spec in
both SAML and OIDC syntax, might help to clarify intent and reach a wider
range of readers.

*Catering to different reader roles*
The spec does a good job of describing FastFed in its entirety, but it is
somewhat hard to use if the reader is consulting it with the intent of
implementing a real system. One reason is that SP and IDP parts are mashed
together. It might be handy to separate them, or at least to decorate the
relevant sections so that SP and IDP implementers have a very clear way of
identifying the parts under their responsibility. Also: although the spec
is named "core", it contains optional parts - although they are formally
well defined, again for the sake of readability it would be useful to be
explicit about what constitutes MVP and what's optional.

Somewhat ill-timedly, I am heading out for two weeks of time off hence I
won't be able to engage right away- but wanted to put the message out. I'll
do my best to join one call once back in case you want to dig deeper in any
of those items.
Thank you, looking forward to contributing to the WG.

Cheers,
V.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20211116/ff54c8a6/attachment.html>