Subject: Missed Items

From: "Gareth Richards" <[email-masked]>
Date: Thu, 13 Dec 2001 17:33:21 -0000

Due to the BEEP discussions, there was not time for a number of the
proposals contained within the I-D Delta to be raised.

1. Fingerprint
The I-D has a LastModified element in the credential format (section 3.2).
The proposal is that this be replaced with a fingerprint which would be
used as follows:

a) Optionally returned by the server in the upload response (Framwork
section 5.1).
b) Optionally sent with the credentials in an upload request.  If it is not
included then the credentials are replaced unconditionally.
c) Optionally sent along with the credential selector in a download
request(Framework section 5.2).

The intention is that if the client has locally cached credentials then it
could use the fingerprint to conditionally download credentials if they are
newer.

2. Multiple Credentials.
The I-D has the credential selector as an optional argument in upload and
download requests (section 2.4).  If the selector was omitted then it is
used to select the default credentials.  We felt this could be potential
for confusing since the notion of a user's default credentials could vary
over time.  For example, if a user uploads credentials "cred1" and later
credentials "cred2" then "cred1" will be the default.  If "cred1" is later
deleted then presumably "cred2" would become the default and would be
downloaded with a null selector name.  There is similar possible confusion
during credential upload and delete when a user could inadvertently replace
the wrong credentials.

The proposal is that there will be no default credentials and that all
credentials must have a selector unique for that account.  The selector
would be required for upload requests and optional for download requests.
If omitted in a download request it would be interpreted as a request for
all the stored credentials.

3. Authorisation ID
Section 2.2 of the ID requires that the BEEP session MUST set the
authorisation identity to the same value as the authentication identity.
It is not clear why this restriction is required and we therefore proposed
that if an authorisation ID was specified during the SASL negotiation then
it would be used to identify the account used.  (We could think of no
particularly compelling reason for doing this, we just couldn't think of
any reason why it shouldn't work that way.)

4.  Credential Format
The credential format (section 3.2) contains a KeyID containing an XKMS
related URI.  This seemed to be putting XKMS specifics in the SACRED PDU
which should ideally treat the credentials as an opaque blob.

5. ProcessInfo
Since xbulk:ProcessInfo is in the UploadRequest, it does not seem to be
required in the CredentialType (section 3.2).  It would be possible to pass
the required information as part of the basic request.

6. TimeToLive and ClientInfo
The same credential element is used for credential upload and download.
This type contains TimeToLive and ClientInfo elements that contain
information from the server to the client.  Since there is no reason for
the client to return this information we propose removing them from the
upload request.

7. Error Status.
This issue could be seen as BEEP related but whichever transport or
authentication system is used there will need to be a way of reporting
status information back to the SACRED client.  We therefore propose that
each response message should contain a status attribute and optional
human-readable descriptive text.

Gareth Richards

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Dec 2001 18:31:55 +0000

I don't understand what you mean - care to give an 
example?

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Dec 2001 18:33:36 +0000

I disagee. 

- Why can't a client choose/influence the TTL setting?
- The ClientInfo field is only interpreted by the 
  client and therefore has to be in the upload.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Dec 2001 18:34:32 +0000

Adding this is fine by me.

---

From: "Gareth Richards" <[email-masked]>
Date: Fri, 14 Dec 2001 12:06:06 -0000

The UploadRequest element is defined in the schema as containing a
NewCredential and an optional xbulk:ProcessInfo and the
sacred:CredentialType also contains an xbulk:ProcessInfo.

	<element name="UploadRequest">
		<complexType>
			<sequence>
				<element name="NewCredential" type="sacred:CredentialType"/>
				<element ref="xbulk:ProcessInfo" minOccurs="0"/>
			</sequence>
		</complexType>
	</element>

All we were suggesting was that it is not needed in both places.  To pass
vendor specific information to the server it could just be made an optional
part of all client request PDUs.

---

From: "Gareth Richards" <[email-masked]>
Date: Fri, 14 Dec 2001 15:13:55 -0000

I had assumed that the information for the TTL and ClientInfo would have
originated at the server from the server's security policy.  However, if
the server just acts as a storage for the clients credentials then this
will not be the case.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Dec 2001 14:34:01 +0000

Gareth,

Sounds ok to me.

Stephen.