Subject: Implementation Results and IOTP Items - AlogrithmRefs/Data

From: "Smith, Chris" <[email-masked]>
Date: Fri, 21 May 1999 15:42:00 -0400

In AuthData, we specify a content model of

<!ELEMENT AuthData (PackagedContent+, Algorithm+)> 
<!ATTLIST AuthData
 ID                 ID      #REQUIRED 
 AuthenticationId   CDATA   #REQUIRED 
 TradingRoleList    NMTOKEN #IMPLIED
 AlgorithmRefs      IDREFS  #REQUIRED 
 ContentSoftwareId  CDATA   #IMPLIED >

The intent is that the software and user together may choose a single 
entry from AlgorithmRefs, and use the appropriate Algorithm and data 
from PackagedContent.

Two problems:

1) An algorithm might conceivably require NO data, especially if it is 
dependent on a hardware token. PackagedContent should likely be repeated 
as (*) not as (+).

2) There is an unwarrented assumption here, that all algorithms can 
operate over the same PackagedContent. This is clearly not going to be 
the case. However, there is no way to assign individual 'packages' to 
the various algorithms.

There are a couple of ways out of this.

1: Limit AuthData to a single Algorithm and allow AuthData to repeat. 
Then it is a matter of choosing from multiple AuthData, not from 
multiple AlgorithmRefs. In such a situation, AlgorithmRef would be 
dropped as redundant.

This strikes me as the most useful, since the most common case will 
likely be a single choice of Algorithm.

2: Find a way to associate individual packages with algorithms. Do not 
use the package names for this, as the individual algorithms may have 
already used those for their own purposes. This might be done using the 
ID attributes from the PackagedContent items.

This would work, but I still prefer 1:

===================================================================
Chris Smith, Royal Bank, 416.348.6090, [email-masked]

---

From: David Burdett <[email-masked]>
Date: Sat, 22 May 1999 02:50:45 +0100

I agree with Chris's point. However the change is not quite as simple as
chris suggests since if you repeat the AuthData component, then it creates a
problem since AuthData also contains a "TradingRoleList" attribute which is
used to request Organisation information about the Trading Roles which an
individual or organisation wants to take in the Trade. If we repeat
AuthData, then we are duplicating the request for Trading Role information.

In reality, requesting Organisation information is separate and distinct
from authentication a Trading Role. So really, these should be two separate
requests, so that the we have:
*	an Authentication Request which just does an Authentication, and
*	a Trading Role Information Request, which requests the return of
Organisation information about one or more Trading Roles.

Finally, Authentication Data now *only* occurs inside an Authentication
Request Block therefore propose changing the name of the Authentication Data
Component to Authentication Request Component and its DTD name from AuthData
to AuthReq. This then mirrors Authentication Response more accurately as a
request and response exchange.

Change to the specification are described below.

David

TRADING ROLE INFORMATION REQUEST
================================
This is a new component with DTD as follows:

<!ELEMENT TradingRoleInfoReq EMPTY>
<!ATTLIST TradingRoleInfoReq
 ID                 ID      #REQUIRED
 TradingRoleList    NMTOKEN #REQUIRED >

 ... where TradingRoleList has the same defintion as in AuthData, and with a
description of ...

"This Trading Component contains a list of Trading Roles (see section 2.1)
about which information is being requested. The result of a Trading Role
Request is a set of Organisation Components (see section 7.6) that describe
each of the Trading Roles requested."

Example usage includes:
		*	a Merchant requesting that a Consumer provides
Organisation Components for the Consumer and DelivTo Trading Roles
		*	a Consumer requesting from a Merchant, information
about the Payment Handlers and Delivery Handlers that the Merchant uses."

AUTHENTICATION DATA (REQUEST) COMPONENT
======================================
Change Authentication Data DTD from:
<!ELEMENT AuthData (PackagedContent+, Algorithm+)>
<!ATTLIST AuthData
 ID                 ID      #REQUIRED
 AuthenticationId   CDATA   #REQUIRED
 TradingRoleList    NMTOKEN #IMPLIED
 AlgorithmRefs      IDREFS  #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

... to ...

<!ELEMENT AuthReq (Algorithm, PackagedContent*)>
<!ATTLIST AuthReq
 ID                 ID      #REQUIRED
 AuthenticationId   CDATA   #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

... with a description as follows ...

"This Trading Component contains parameter data that is used in an
Authentication of one Trading Role by another. Its definition is as
follows."

Note that reference to Challenge Data has been removed as some
authentication algorithms don't need challenge data.

AUTHENTICATION REQUEST AND AUTHENTICATiON RESPONSE SIGNATURES
===========================================================
Add the TradingRoleRequestInfo component as one of the components to be
signed in both these sections.

AUTHENTICATION REQUEST BLOCK
============================
Change the Authentication Request Block from: 

<!ELEMENT AuthReqBlk (AuthData?) >

... to ...

<!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?) >

.. and change the defintion AuthReq (AuthData) to read ...

	"If the Authentication Request Component (see section 7.2)is not
present it means that the Authentication Request Block is just requesting
the return of Organisation Components which describe the Trading Role that
received the Authentication Request Block. 

	If one or more Authentication Data Components are present then each
describes an alternative way in which the Trading Role receiving the request
may authenticate themselves. The receiver of the Authentication Request
block must use the Authentication method specified if there is only one or
make a choice based on preference if there are more than one."

AUTHENTICATION RESPONSE BLOCK
Change the DTD from ...

<!ELEMENT AuthRespBlk (AuthResp, Org*) >

... to ...

<!ELEMENT AuthRespBlk (AuthResp?, Org*) >

... as the Authentication Response is only required if there is an
Authentication Request component present in the Authentication Request
Block.

AUTHENTICATION TRADING AND DOCUMENT EXCHANGES
=============================================
Updated to reflect introduction of Trading Role Information Request.

> ----------
> From: 	Smith, Chris[SMTP:[email-masked]]
> Sent: 	21 May 1999 12:42
> To: 	[email-masked]
> Subject: 	Implementation Results and IOTP Items - AlogrithmRefs/Data
> 
> 

**********************************************************************************************

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]