[Openid-specs-fastfed] Oct 9, 2019 WG meeting notes

[McAdams, Darin]

Sorry I was out last week. Thanks for the notes. Want to ensure I incorporate any feedback for the spec. Have a couple questions/comments below.
-Darin

>> [In section 7.2.3.2] Should make this numbered to make impl easier?

Already done! Nat inspired me at the OpenID meeting when he mentioned using numbered lists in his work and how that made it easy to link the conformance tests back to the spec. 

>> Where does key information come to validate the response from the IdP?

Is it answered by 7.2.3.2, bullet #1?
<snip>Verify the JWT signature using the current JSON Web Key Set [JWK] hosted at the jwks_uri captured in Section 7.2.1.5.</snip>
LMK if still unclear. Can add more examples/guidance.

>> In Section 7.2.3.2 -- bullet #2, #3 logically come before #1

#1 is referring to the JWT signature validation. Guessing this feedback derives from the fact that you need to extract the provider/tenant information from the JWT first before you can lookup the right JWK Key Set and validate the signature? Hence, it makes sense that signature validation would happen after reading the JWT contents.

>> Can we clear up what "urn:ietf:params:fastfed:1.0:provisioning:SCIM:FullLifeCycle" means in terms of directionality?

It's a push from IdP->App. Basically, the vanilla SCIM usage that most Apps have today.  Could rename it "...SCIM:PushToApp"
If other SCIM behaviors are needed, intent was to define those in their own profiles. For example, if HR systems want a bi-directional flow, can imagine an additional profile named "urn:ietf:params:fastfed:1.0:provisioning:SCIM:HRServices_BiDirectional" (or whatever name makes sense).
Microsoft mentioned another flow where Azure hosts the SCIM service and the App pulls on demand, sort of like the UserInfo endpoint in OIDC-land.  Can imagine that being another profile "...SCIM:PullByApp" that inverts the responsibilities around.

>> Do we want to be opinionated about users and groups in provisioning?

Curious to learn more. Is this about the interop requirements? As we (in AWS) implement a SCIM service, we're finding that some of the IdPs don't necessarily behave as documented when it comes to group provisioning. More consistency would be welcomed.

>> Application assurance and risk analysis

Reviewing the notes, the discussion looks related to the fact that well-known apps (e.g. Salesforce) may require less scrutiny by an IdP administrator than, say, "JoesFlyByNightSketchatorium".  IdPs may want to know the risk levels so they can guide administrators along safe paths during approval workflows.
 
The current spec provides a way to uniquely identify an app, but abstains from defining the risk profile of apps. The thought was risk scoring can either be another layer atop FastFed, or completely open to implementation. The choices illustrate a common tension observed in many security businesses -> Specifically, will vendors hoard their security knowledge and sell that to customers as a differentiator, or will they prefer to share the knowledge so we all become collectively stronger. I don't know which way this will tilt. I think it's a discussion amongst the IdP vendors and some may come to different conclusions.

BTW - The "provider_domain" is the unique identifier for the app. See Section 8.3 ("Security Considerations") and 4.1.1 ("EndPoint Validation").  This is the part of the spec worth getting a diverse set of appsecs eye upon, as getting this wrong lets one app impersonate another.




From: Openid-specs-fastfed <openid-specs-fastfed-bounces at lists.openid.net> on behalf of Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net>
Reply-To: Erik Gustavson <erikgustavson at google.com>
Date: Wednesday, October 9, 2019 at 6:34 PM
To: Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net>
Subject: [Openid-specs-fastfed] Oct 9, 2019 WG meeting notes

Hi folks, 

Here's the notes from today's call.

-Erik


Attendees
Erik Gustavson, Google
Matt Domsch, Sailpoint
Adam Hampton, Sailpoint
Gokul Baskaran, Target
Agenda
• 
• Sailpoint has continued
•  work on the demo, some questions about implementation:
• 
• 
o 
o Where does key information
o  come to validate the response from the IdP?
o 
o 
o In Section 7.2.3.2 -- bullet
o  #2, #3 logically come before #1
o 
o 
• 
• Should make this numbered
•  to make impl easier?
• 
o 
• 
• 
• Review of the doc that Brian
•  sent a few weeks ago
• 
• 
o 
o Matt: Governance provider
o  flow -- comments?
o 
o 
o Erik: Would this work if
o  we sub Governance for any other future service? This is somewhat FastFed update flow (i.e. FastFed provider has new capabilities)
o 
o 
o Matt: So is FastFed idempotent
o  thhen?
o 
o 
o Erik: perhaps only if there’s
o  nothing new at the IdP? We should try doing this flow in the simple case
o 
o 
o Matt: Directionality wasn’t
o  really resolved
o 
o 
o Erik: discussed at IIW -
o  any other cases besides HRM use case?
o 
o 
o Matt: ADP was asked to push
o  into the IdP. Primary model is still IdP acts as client to SP’s server. Spec is still too vague here. (4.1.4)
o 
o 
• 
• Can we clear up what "urn:ietf:params:fastfed:1.0:provisioning:SCIM:FullLifeCycle"
•  means in terms of directionality?
• 
• 
• Erik: Should we just require
•  directionality (client vs server) returned in 4.1.4 (“capabilities”)?
• 
• 
• Erik: let’s discuss in two
•  weeks with more of the group
• 
o 
o 
o Gokul: Do we want to be
o  opinionated about users and groups in provisioning?
o 
• 
• 
• Risk analysis or guidance
•  during any self-service flows
• 
• 
o 
o If IdP automates acceptance
o  of the FastFed handshake, what guidance on best practices should we have in the standard? I.e don’t depend on there being a human who is reviewing the federation/provisioning request
o 
o 
o Erik: Think this is up to
o  IdP impls
o 
o 
o Gokul: What about high value
o  or high assurance apps like a Salesforce?
o 
o 
o Erik: I think this is about
o  identifying SPs so IdP knows how to handle them. During handshake do we provide enough information to know how to handle different flows after handshake?
o 
o 
o Gokul: Could we have self-service
o  of handshake in the current model if there are different levels of application assurance?
o 
• 

Next Meeting
October 23, 2019
• 
• Hangout:
• https://meet.google.com/wht-tipi-uoa
• 
• 
• Phone: +1 832-509-0551‬
•  PIN: ‪164 241‬#
• 



-- 


Erik Gustavson
mailto:erikgustavson at google.com
Engineering Manager - Cloud Identity
415-736-3425