Re: [pki-tc-chair] Oasis PKI contact list

[Stephen Wilson <swilson@lockstep.com.au>]

Thanks Steve.  Nice to meet you June!  

Speaking for the Australian IT Security Forum, we'd be very happy for the 
paper to be used as a resource in the Oasis education work.  Equally, I 
may be able to develop the work further, in consultation with your 
directions.  I think there is great need for high level guidance for 
developers implementing embedded PKI, in application or scheme specific 
situations.  Designdecisions need to be made around parsing Policy OIDs, 
interoperability, User Interfaces etc. 


Some other comments in line below. 

Cheers, 

Steve.



> I have reviewed the paper you sent yesterday.
> 
> Speaking as the PKI TC co-chair, I think you
> should get in touch with our Education Subcommittee.
> The paper may be useful as a resource in this
> group's work (gathering and supplementing
> educational materials on PKI). June Leung of
> FundSERV is the chair of this SC. I have sent
> her a copy of your paper and cc'd her on this
> email.
> 
> Speaking as an individual, I agree that PKI
> has great value in high-volume applications
> with automated processing. However, I think
> that it can also have significant value in
> other situations, such as identifying individuals
> in a multi-application high-security business
> environment like financial services. June may
> want to comment on this, since it's FundSERV's
> business.
> 
> I also agree that it's not realistic (and perhaps
> not desirable) to expect a single credential
> to serve for all purposes. However, I think
> there are situations where a credential may
> be multi-use. For instance, the Sun employee
> ID card can be used for building access,
> purchasing items in our cafeteria, logging
> in to our machines, authenticating to
> corporate software systems, accessing the
> corporate VPN, etc. 

Absolutely.  What you describe is a class of tightly coupled applications, 
that all hang off the relationship that Sun has with its employees.  The 
ID card instantiates that relationship (rather than instantiating or 
expressing a more general purpose statement about a person's personal 
identity).  PKI will really take off when we start to use it to express 
someone's status in some pre-defined business context. 

I'd like to suggest that at some level of abstraction, the whole suite of 
Sun ID card usages can be thought of as one common class of application --
 "Sun2staffer"?  At that level of abstraction, we will see that the ID 
card cannot "interoperate" directly with other business applications.  

Interoperability is one of the great sticking points isn't it.  I find 
that only rarely do people set clear expectations for what they want out 
of "interoperability".  I actually heard a bunch of government regulators 
in the early days of Identrus say won't it be great when my card with Bank 
X will work with Bank Y?!  They were imagining a single account. 

At one level, Bank X's cards do interoperate with Bank Y's -- in that 
they're all ABA compliant, so if you stick Bank X's card into Bank Y's 
ATM, the card will be read perfectly well.  So well in fact that Bank Y 
ATM may recognise the card as not belonging to that bank and will alert 
the user to try another card.   


> Through a federated
> identity system or cross-certification,
> we may soon be able to use our ID card for
> accessing external systems as well (such as
> travel reservations).

It strikes me that federation will work with different degrees of 
effectiveness at different levels of application-classes and super-
classes.  For instance, it will be relatively easy to federate indentities 
in the finance sector, since there is a common level of ID proofing across 
all institutions, that is, the Know-Your-Customer rules.  At least in 
Australia, the KYC Rules explicitly call out recognised credentials like 
passprts and drivers licences, so it will be relatively easy to federate 
banks' IDs back into social security services for example.  

But I think it will be difficult to federate identity across domains of 
professional qualifications.  If I have a medical qualification 
(instantiated as a smartcard issued by a recognised professional body) it 
doesn't map well onto say my identity as a business person.  

I have seen people try to quantify the level of ID proofing implicit in a 
medical qualification, by looking back over the process of going through 
university, presenting identity documents, etc over years.  It's very hard 
to ascribe X number of 'points' of ID proofing to this process.  

It seems much easier to me, and much less risky, to just accept that 
the "identity as a qualified doctor" is quite separate from "identity as a 
business person".  And it's a practical way of looking at things too 
because the software applications I use when acting as a doctor (and the 
context in which I use those apps) are quite different from the apps I use 
when acting as a business person.  

Woops ... sorry for slipping into a rant!! 

> The main downsides to requiring separate
> credentials for separate systems are:
> greater cost of issuance and management,

... this point deserves further research but my strong guess is that the 
Total cost of managing say five contex-specific credentials [my bank 
accounts, my employment card, my social security card, my professional 
memberships etc.] will be less than the cost of trying to engineer a 
single super identity. 

> ... difficulty keeping separate credential
> systems up to date, 

... the business processes for many separate credential systems are 
already autonomous and well maintained.  It might be more costly in fact 
to try to get professional bodies in particular to modify their systems to 
make use of federation. 


> ... and less convenience
> to the user (who must carry several cards
> and remember several activation PINs).
> That's why Sun consolidated on a single
> employee ID. I'd like to see this reflected
> in your document.
> 
> Thanks,
> 
> Steve
>