Re: [trust-el] Groups - Discussion draft of first deliverable for F2F uploaded

[Tony Rutkowski <tony@yaanatech.com>]

Rather than just kvetching about materials,
perhaps some substantive observations would
be useful.

1. I would have expected as the principal first
example to be something akin to "trusted
institutional record." This would include
government, educational, employer, financial,
and service institutions. The first example
almost gets there, but is funkified with the
construct of a "reuse of primary authenticator
method."

2. The current list needs to be harmonized in
some fashion. A present, it's largely 22 things
tossed out there with considerable redundancy
with a certain amount of weirdness like "customer
retention." Presumably this process was planned.
Stripping the examples to their basic titles,
they are:

o Reuse of Primary Authenticator Method
o Customer Retention
o Cloud Access
o Static Knowledge Based Authentication
o Session Elevation to Level of Identity
Proofing
o Hub Provider of Pseudonymous Identity
o Step-Up Authorization
o Multi-channel by Phone
o Generic Knowledge Based Authentication
o Address Verification Service
o Split Large (Risky) Transactions into
Multiple Smaller Transactions
o Use of Tokenized Device/Network Attributes
o Trust Elevation by Hard Token (OTP
Generator)
o Multi-Attribute-Based Trust Elevation
Service (AKA Fraud Detection)
o Emergency Access to Patient Healthcare
Information – a European Method
o Trust Elevation by Address Authentication
with Additional attributes Service
o Trust Elevation by Hard Token (Smart Card)
o Trust Elevation with PKI Certificate
o Authentication Context Mapping Method –
Request Authoritative Identity Attributes
o Secondary Approval of a Financial
Transaction on Mobile
o LOA-3 Using Online Identity Proofing via
OTP and KBA
o Uniform Reliability and Revocation Service
(URRS)

3. At some point, these use cases will presumably be
schlepped into an appendix and a good methods matrix
will be placed up front.

4. You state in the scope that non-person entities
will be eschewed. However, you include object in
a great many critical ways as part of the construct:
IDPs, tokens, credentials, etc. You even mention software
viruses. We encountered this conundrum in the ITU-T
IdM Focus Group work. Persons are in fact just a
type of object, and you can't neatly extract the subject
matter from the world of object trust and identity.
It's also one of the reasons why the rather significant
cloud trust work occurring in the TCG and the CA/B
Forum are so important. Indeed, the logical
extrapolation of the subject also includes SCAP and
Continuous Monitoring platforms. Here's I'd look
especially to the rapidly ramping work in the IETF
under the SACM aegis.

5. The new MITRE/DHS CybOX work should have significant
benefit when applied to Identity Management. It potentially
solves one critical challenge - a uniform means of capturing
"identity signature" information associated with transactions.
CybOX is also just plain cool!

Just some thoughts....

--tony