Missed Items

The previous version of this mail was sent by mistake.

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) Returned by the server in the upload response (Framework 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