[Openid-specs-fastfed] Open questions on Darin's draft

[Hardt, Dick]

Hey FastFed

Here are areas of further discussion from Darin’s draft. If any of the topics starts off a discussion here on the mail list, let’s fork the thread and rename the topic.
We will start discussing this in our call next Wednesday.

/Dick

(1) Attributes - Descriptions & Mappings
There several instances in the proposal where a participant conveys information about the user attributes they vend/consume.
Discussion points:
·         The proposed identity provider metadata includes a description of “Supported Attributes”. The intent was for a provider to indicate what it could provide, so that services can halt the registration if necessary attributes are missing. Does the group think this metadata would be used in practice, or it is unnecessary?
·         The service provider metadata allow the expression of which attributes are required vs optional for the service. The intent is to allow a human administrator to see which attributes will be released, and to bulk-approve the release of user attributes for all members of the organization in advance, rather than asking each end-user to approve. Any concerns with this decision? And, is optional-vs-required a rich enough vocabulary to convey the needs, or is additional information necessary.
·         The proposal is opinionated about differentiating between a “logical expression” of attributes vs. the “physical manifestation” of attributes. It requires consensus on the logical vocabulary (e.g. everyone uses “displayName” to represent the displayable name of the user), but allows each service provider to define how to bind those attributes into SAML/OIDC messages.
o    The logical portion uses a structure based off SCIM. However, the SCIM specification does not currently define a mechanism to describe which SCIM attributes can be vended/consumed, and whether they are required/optional. Any prior work in this area? Should this be part of FastFed, or should there be an independent extension to SCIM which FastFed leverages?
o    Binding the logical attributes onto the physical SAML/OIDC messages requires a mapping syntax. Similar to the previous question, should this be part of the FastFed spec or an independent extenstion to SCIM? Is the proposed mapping syntax sufficient?

(2) Metadata Format and Contents
The FastFed proposal describes two configuration files: a public “Discovery” file, and a private “Metadata” file.
Questions for the group:
·         Any concerns about splitting the files?
·         Do they contain the right information? Is anything missing? Should anything in the private file be public?
·         The format is simple JSON key/values. OTTO has defined a richer metadata structure. Should FastFed apply a similar pattern?
·         Does anyone foresee future extensibility needs that cannot be met by the proposed format?

(3) Entitlements
Some applications offer different profiles/roles that users can attain. The permissions to do so are sometimes represented in extended attributes on the user profile, inside the Identity Provider.

Custom attributes are generally in conflict with the FastFed goals because they require an administrator to define/configure additional data. However, the need for profile management still exists. Can FastFed support these custom attributes without sacrificing usability?

If there is enough commonality in the representation of entitlements, it might be possible for FastFed to define a mechanism for Service Providers to declare the set of profiles/roles that can be attained.  However, this is a slippery slope. Authorization rules become complicated very quickly. It is undetermined if this is possible or appropriate for FastFed to address.

(4) Credential Exchange
FastFed needs to distribute credentials to the IdP and SP so they can communicate with each other. OAuth tokens are nice, but there is no existing OAuth grant type that aligns with the FastFed needs. An unorthodox flow is proposed. Does anyone have concerns with the flow and wish to suggest alternative strategies?

(5) Certificate/Key Rotation
The initial configuration of SSO is just the beginning. There is ongoing responsibility for certificate/key rotation. With the goal of “simple federation”, how opinionated should FastFed be at specifying the rotation requirements to be FastFed compliant?  For example, is it practical to require that all parties support SAML certificate rotation without downtime?

(6) User Provisioning/Deprovisioning
May apps require user provisioning. With the goal of “simple federation”, FastFed needs a way for service provider to express their desired provisioning mode so that FastFed Compliant providers can make it “just work”. There should be a small number of easily understood modes. What are they? Two candidates are “None” and “JIT”. Perhaps also “Preprovisioned”.  Are those sufficient?

Deprovisioning is more complicated. Feedback from a large enterprise player is that SCIM’s boolean “active” flag is insufficient to represent their user modes and deprovisioning requirements. They implement custom deprovisioning logic for each application. Let’s review this feedback and consider whether FastFed can meet the deprovisioning requirements.

(7) Endpoints on the public internet
The flows described in this document require that an SP be able to communicate programmatically with the IdP. For example, to load the FastFed Metadata configuration, refresh OAuth tokens, and rotate keys. Many existing installations of SAML IdPs exist in private networks with firewall restrictions. They may not be able to call (or be called) via endpoints on the public Internet. This has not mattered in the past because SAML relied on the user_agent as a data carrier.

Question for the group – Is this a serious roadblock that needs to be considered? If so, it may be necessary to define a FastFed flow that performs the registration handshake through the user_agent via HTTP POSTS, and negates the need for public endpoints. This profile may only support a limited subset of FastFed functionality.

(8) Terminology
FastFed is unique in that it spans three existing specs, each with unique terminologies. Does FastFed foist a 4thterminology on the world? Any suggestions for that terminology?

(9) Threat Model Review
As the specification gets closer to finalization, a threat model will be performed. Let’s review the results with a critical eye.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20170524/e2307f76/attachment-0001.html>