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


Anders,

Given this posting - I must say - I concur with Monica - that the BPSS - 
especially what we
are architecting in BPSS V2.0 allows you to control these interaction 
modes for descreet
BTA (Business Transaction Actvitiy) exchanges, and participant roles.

If you want to see some models that enable you to do this - look at 
these examples - and
how you can control modes at the BTA level.

 http://drrw.net/visualscripts/

Of coruse this works within an ebMS environment - your mileage may vary 
elsewhere ; -)

Thanks, DW
=============================================================
Anders Rundgren wrote:

>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
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/egov/members/leave_workgroup.php.
>
>  
>




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