Had a good discussion of time frame in our discussion last week as we talked about our Roadmap
Goal is to have everything completed by Q2
Impact of CSP Role re-assignments to Kantara IAF / Agile IAF
Andrew had sent an email describing the situation. We have been asked by the ARB to provide IAWG thoughts on the impacts of this model, whether it is feasible or possible.
We are looking at the partial approval of a service.
The way we've segmented the approval process today, a Service can be approved against a specific subset of the SAC, however the big question is the approval of a full complete service where a specific company may take on one subset and another company will take on other piece versus approval of just one subset provided by one company.
One of the questions is: Can the Kantara IAF be used for anything other than FICAM? It should be able to. Under the terms of FICAM approval, there is only the full-service concept. But for other programs, where someone is not searching for FICAM approval, we should be able to be more flexible.
The immediate case is the ID proofing being pushed down to a different party. Can we accept a third party approval? Do we have to pay attention to it at all? Does it break federation interoperability?
Discussion
there are two different approaches to handle this: one is to issue an audit finding on a comprehensive end-to-end service, or whether we decide to provide some kind of approval on a piece-by-piece basis, at which oint we'd need to understand if there are any additional complications in coming it in piecemeal (if the pieces are good but together are broken)
if we try the first approach, a clear audit process from end-to-end, that could be a scalability problem for Kantara - would we have to assess every RP for their ID Proofing component? yes, we would
concern with piece-by-piece basis is that the credentials that are issued under the service where the RPs are doing the ID Proofing would not be interoperable because they would/could be done on a proprietary basis without independent review. Would we be going against the premise of interoperable credentials?
That assumes where the binding of the credential is being done. It is possible you have an anonymous credential and you are certifying the strength of that credential and the verification of that credential.
What we are looking at is a market place of different components, and 800-63 does describe a variety of different components. We are the ones drawing the lines around the component to define what is a full service. We may want to consider being able to certify that independent component and we may want to support IdP both inside and outside a federation, where the federation may choose to allow components or perhaps require a full IdP. This componentized model does align with what some of the marketplace is asking for. What becomes critical is how the identity is bound to the credential, so you can rely on the strength of the credential itself and know that the binding is consistent. The RPs don't have to rely on each other if they are independently binding to a credential.
What is approved is the credentialing not the binding of the identity to the credential, or the identity associated with the credential, and that is the service that has to be replicated over again.
Would that end up being a separate service to be specified?
If you look at the existing requirements, 800-63 has defined requirements for those functional components. In the credential management area, there are some requirements given to the registration authority and some that get given to the credential issuer, and there may be requirements they both share and other that are specific depending on the strength of the binding operation
From the standpoint of the IAF, would this be a separate process? There might be two parts to that. One might be a profile to cover additional requirements. For the approval part, it is the same approval process. The Assessor would conduct their assessment, gather evidence, notice deficiencies, etc, because you have to specify the scope as part of the package?
Who would receive the certification? Both parties only while they are working together? That's part of what we're trying to decide here. In having an IdP component and a Credential Management component, there is no standardized interface for that at this time. Each service offering is just different since there are no standards. They have to have a contract identifying the boundary. Kantara, however, doesn't care since we are looking end to end for FICAM approval.
We could see RPs not wanting certification themselves, but wanting to see certification for a component as part of their market decision.
Kantara would only look at the piece that the service is bring forward for certification. If they are having a contractual relationship with the RP, that part would not be part of the Kantara assessment.
We keep talking about RPs here. Kantara has yet to come up with an assessment criteria around how an RP works with data they receive from a Credential Service provider in terms of protection of PII, etc.
A valid point. As a strong credential provider, they have no data being provided to the RP. The RP holds the PII, not the credential provider.
For an end-to-end service, having some comfort that the RP is behaving appropriately would be good. We do have the RP guidelines on our roadmap, but still looking for a champion or market driver for that work.
It is absolutely a valid concern, but may be a different discussion than the Agile IAF part, the function of identity verification done by someone, RP or otherwise.
The answer might be that it is not that these requirements are incumbent on the RP but instead incumbent on whoever verifies and manages the binding between the credential and the PII.
Could this lead towards a proliferation of bilateral agreements? Avoiding that is why we went to various models of federation.
Kantara is approved by FICAM to do approvals. Is it assumed that the services we approved are part of a federation that uses this approval? At least some CSPs contract directly with their clients, not with a federation. Kantara operates a trust framework but is not a federation.
Is the purpose to support federation, or in the business to certify entities that have the flexibility to enter in to these one-to-one relationships? Are you in the business to certify components that can be put together to become an IdP and operate in a federation? How flexible does Kantara want to be?
We should support self-trust models.
Who is the consumer of the Kantara Trust Mark? Is it the RP? The CSP? The federation operator? The end customer? If Kantara says we can put our trust mark on all subcomponents or some mix, who needs to trust that trust mark?
If we want to have that "good housekeeping seal" it is up to the RP to decide if that is the type of service they need and then still have some assurance around that.
Everybody needs to be able to consume it from any other party.
One of the tools Kantara is building is the Kantara Trust Registry, which is currently the trust status list. If we went to the multiplicity of trust marks, the Trust Registry might be useful to help confirm what the trust mark is for.
Being on the credential side with many attribute providers and identity providers, an RP may want to go to one of those services to do the identity proofing, but keep the credentialing in house. Right now the Kantara model supports that, providing a list of approved services, but there is not a similar model if they want to do identity proofing in house and have the credentialing handled externally.
Kantara has to have a way to approve the interoperability-worthiness of the entire end-to-end identity process and identity usage.
If we can move forward with this process and we have all the pieces, do we have to do a comprehensive interoperability process to show it all works together? yes, we need to do that. Having to implement that interoperability testing, which we have discussed in the past, is on Kantara's roadmap.
There is a certification criteria defined by industry that the government has agreed with = FICAM. That is just one aspect of what Kantara can do, so we should allow FICAM to 100% drive what Kantara can do.
note that FICAM is also US-centric, and we need to be more global in our scope.
Is Internet identity portable or credential-bound? Are we requiring that credentials are always bound to a specific Internet identity? That is a bigger question than we can handle on one call, but it has implications for our work.
We do know that FICAM is considering moving to a more componentized approach. Other countries are also moving to that model as well. In terms of keeping up with the market place we need to look at how we can be there to support those that are moving in that direction.
Note that the Canadian does not support bound Internet identity.
So, we do have a precedent for this in the Canadian model.
The general consensus is as long as we can caveat a certification in noting that it is just for credentials and that the identity proofing component may need to be redone, and that some level of interoperability would need to be performed prior to a full service certification.
So, what is the implication against the IAF? Do we need to change the IAF to accommodate this? The SAC probably doesn't need to change, but the AAS would need to change in the criteria of what can be approved.
A possible functional component that could help sort this out is an identity registry that could accumulate attestations from identity providers and be a source of a richer set of information about the binding. This could have a spot in the component diagram.
Do we have clear definitions on the different components for us to be able to articulate the different certifications that could be available? Look in the IAWG wiki space under working drafts for some thoughts around that.
Given we have a organization in the queue that works against this kind of component model, Kantara needs to determine if they can be FICAM approved.
Next steps
Andrew to write a document describing the goals and model and identify any additional areas that need further discussion
Errata review (see email sent to list)
To be covered on the next call
AOB
Next Meeting
Date: Thursday, 28 March 2013
Time: 07:00 PT | 10:00 ET | 15:00 UTC (time chart)
United States Toll +1 (805) 309-2350 Alternate Toll +1 (714) 551-9842 Skype: +99051000000481