Subject: RE: Implementation Results and IOTP Items - AlogrithmRefs

From: "Smith, Chris" <[email-masked]>
Date: Tue, 25 May 1999 11:56:00 -0400

This will work as long as the text description makes clear that some 
Algorithms may need information to be returned in the Org as well.

When this is necessary, the specifcation for the algorithm should 
indicate so.

Otherwise, I like this - it makes clear that in some cases (withdrawal, 
for example) I don't care who you are as long as you can authenticate 
yourself, and in other cases (purchase), I don't care who you are as 
long as you give me a shipping address as part of the customer's Org 
component.

...Chris

______________________________ Reply Separator
_________________________________
Subject: RE: Implementation Results and IOTP Items - AlogrithmRefs/Da
Author:  "David Burdett" [SMTP:[email-masked]] at Internet
Date:    1999/05/21 09:50 PM

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 
>
>
> 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]
>
>
>

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

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]