RE: [iam-discuss] Comments to date on initial draft IAM TC submission

Many thanks Martin

On 3), there is complete flexibility AFAIK. There's more process/voting rigour around a Spec than a Note of course. My sense is have the Spec tight and compact, with one or more Notes as supporting guidance. Chet, Peter, others may have different views of course.

On 4), I suggest making it more explicit in the out of scope piece, that the work will assume identity proofing to a confidence level, binding credentials, and the user in possession of the token and authentication has been successful at a given level of assurance. Then it's clear the TC is picking up the flow at the Authz stage (to the extent that in some deployments these are not so clearly delineated).

Cheers

Colin

Date: Tue, 9 Jun 2015 13:33:28 -0400
From: bfc.mclean@gmail.com
To: colin_wallis@hotmail.com
CC: iam-discuss@lists.oasis-open.org; john.tolbert@queraltinc.com
Subject: Re: [iam-discuss] Comments to date on initial draft IAM TC submission

Colin--thanks for the helpful comments. Responses in-line below . . . .

Martin

On Mon, Jun 8, 2015 at 11:30 PM, Colin Wallis <colin_wallis@hotmail.com> wrote:

Thanks Martin

I have taken another pass through the doc and offer the following..

1) While I agree and support the use of the NSTIC principles and baseline requirements as a guide for the proposed work, I am not sure that the reference to IDESG in (1)b para 3 is entirely reflective of the reality. IDESG has not specified the development of an 'architectural framework' AFAIK. A trust framework, yes, but it is too early to tell if the effort will go as far as developing an architectural framework. It is largely an outcomes focussed org, so my sense is that this is unlikely, compared to say, evaluating a range of architectural frameworks in existence for the purposes of determining conformance with the NSTIC principles, IDESG baseline requirements, and perhaps in future, TrustMark conditions.

I think we are in agreement. Given the high level and work-in-progress nature of NSTIC/IDESG (and FICAM) I think the best we can do is to use the NSTIC Principles as high-level requirements or constraints, and be able to trace how those requirements are satisfied by some configuration of IAM Framework components that meet a specified business case. (Or if not, what technology or standards gap exists that makes satisfying the requirement impossible.) Granted that as the IDESG progresses there may be specific requirements developed which our proposed effort would have to take into account as possible; be the alternative is waiting until everything stops moving, which is probably never.

2) (1) b para 4 and elsewhere mentions 'implementable and testable', and yet the doc is not really clear on what this means. Different folks have slightly different interpretations, so clarification is necessary. To me it suggests a test plan that proves conformance to an implementation of the IAM Framework such that a static test harness could be developed to provide a yes/no pass/fail. that is no small deliverable in its own right, in addition to the others proposed.

The level of test specification we're shooting for is what SE best practice says should be done at the time a functional requirement is defined in order to support later verification and validation. That is, we would answer the question: "how will we know if a component meets the functional requirement?" (Likewise for interface specs, BTW.) We anticipate that testing firms would develop the detailed test suites and tooling, and conduct testing to provide independent certification of conformance and interoperability. I think this is more or less what IDESG hope to do eventually; I think the NSTIC Trustmark pilot is developing something similar as part of their trustmark definitions.

3) (1) b para 5 indicates a target on 1 year for the deliverables, from TC establishment. IMHO with experience of other OASIS TCs this is mighty ambitious, perhaps unrealistically so. That means the work has to be done in about 8 months, to allow for committee reviews and public reviews. There is no distinction between what deliverables are to be a Committee Spec and a Committee Note, which also has a bearing on timelines. This issue of Specs vs Notes applies to (1) d Deliverables sub section as well.

The target is certainly ambitious, and depends on adequate resources participating in the TCs work. You raise another good point in the distinction between Committee Note and Committee Spec. Do we have flexibility in which process to aim for?

4) (1)c para 2. More clarification needed in this scope statement whether identity proofing and credential/token binding is in scope. I don't think so, but happy to be proved wrong.

I admit I am far more interested in developing the AuthZ part of the Framework as I think AuthN has gotten far more attention for a long time. Obviously, AuthN is a necessary anchor for access control. I would welcome advice on how to include AuthN in some way without letting that function dominate the overall effort.

5) (1) c para 3 - 5 and elsewhere. There's normative language (will) and non normative language (may) that needs t be double checked for consistency. Para 3 first sentence is an example.

Thanks--will have a look . . .

I hope these observations are helpful.

Cheers
Colin
Date: Sun, 31 May 2015 22:58:50 -0400
From: bfc.mclean@gmail.com
To: iam-discuss@lists.oasis-open.org
CC: john.tolbert@queraltinc.com
Subject: [iam-discuss] Comments to date on initial draft IAM TC submission

Attached is a list of comments received to date on the initial draft of the OASIS IAM TC proposal submission.

We will continue to collect comments on the draft and the proposed dispositions in this document for at least another week. If it seems useful, we will conduct another concall to resolve proposed dispositions. We will then send out another draft incorporating accepted comments which will be the final for submission to OASIS unless a critical issue is raised.

Thanks again to all who participated in the first concall and others who have provided comments.

Best regards,

Martin

--
Martin F Smith, Principal
BFC Consulting, LLC
McLean, Va 22102
703 506-0159
703 389-3224 mobile

--------------------------------------------------------------------- To unsubscribe, e-mail: iam-discuss-unsubscribe@lists.oasis-open.org For additional commands, e-mail: iam-discuss-help@lists.oasis-open.org

Martin F Smith, Principal

BFC Consulting, LLC

McLean, Va 22102

703 506-0159

703 389-3224 mobile

iam-discuss message