OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

egov message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [egov] Missing Securty: Update Working Draft for Workflow Standards


Regarding
http://w1.181.telia.com/~u18116613/A.R.AppliedPKI-Lesson-1.pdf
I got an interesting off-list comment from an actual implementor
of secure purchasing systems.  Here is some 10% of the comment:

 "From my understanding of how business processes generally work, it would
 be quite counterproductive for P to encrypt a purchasing message to a
 particular OR. OR is almost certain to be a role, and any individual
 associated with that role should be able to engage in a workflow that
 handles the PO"

 "...there are at least 10 different human roles involved
 in the workflow that leads from PO request to PO. Thus I suggest that
 your model not focus on an individual purchaser P, but rather on the
 buying organization's purchasing system server PSS."

 "That is, P may interact with her order system via a web browser,
  and in that case her connection will probably be TLS-protected,
  server-authenticated by server certificate, and client authenticated
  by cert, password, token or some combination."

 "Along those lines, I think one should distinguish the security
 requirements within organizations from those between organizations."

All these statements and particularly the last one, is indeed indicating
that a singular PKI having "employee" as the only entity and clients
as the primary infuser of encryption, is not a suitable foundation for
secure multi-party workflow as the actors actually involved consist
of employees, servers, roles, organizations etc.  In case interoperability
is to be achieved on a wider scale, it is not enough to agree on technical
frameworks, but also on how these actors are supposed to be expressed
identity-wise.  If every organization or community do their "thang",
I believe the rest will not work particularly satisfactory.  I maintain
that this is currently outside of existing standards.  And the reason
is obvious: this is delicate matter.  However, no matter how delicate
or political this subject may be, I think it is at least a good idea to
at east try to specify the options.  This is what I'm trying to do although
the "format" may be somewhat inappropriate.

Anders Rundgren




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]