Subject: RE: [lemonade] Working Group Last Call on URLAUTH

From: [email-masked]
Date: Wed, 20 Oct 2004 07:47:03 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of ext Mark Crispin
> Sent: Tuesday, October 19, 2004 11:35 AM
...
> That is, the "access" rule in the Formal Syntax would have 
> two more rules, 
> "authuser" and "anonymous".  Whether or not the server 
> actually allows 
> this would depend upon server policy.

I'm not sure I understand the use cases for these new access identifiers. 

With URLAUTH there are 3 userids of interest:
1) Userid specifying the locality of the folder containing the target UID, i.e. [email-masked].
2) The authorizing userid.
3) The authenticated userid at the time the URLFETCH is issued.

1 is self explanatory in all cases.

With user+<userid> we have 2=3. This implies the userid was authenticated both by the imap server and the submission entity.

With submit+<userid> we have 3=a user authenticated by the submission entity. 2=a user validated as under the survey of 3.

With authuser+<userid> we have ... well I'm not sure what we have. Maybe 3 is any user that has been specifically given access by 2? This is similar to submit but 3 is not a submission entity?

With anonymous+<userid> we have 3=to any user? This is equivalent to 2 giving access to the world? Maybe a public declaration similar to a public folder message?

Mike

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Mark Crispin <[email-masked]>
Date: Wed, 20 Oct 2004 17:05:46 -0700 (Pacific Daylight Time)

> I'm not sure I understand the use cases for these new access identifiers.

Authuser and anonymous are not needed for Lemonade's 
forward-without-download purpose.

Consider something more general.  I have a message containing an 
attachment that I wish to make available.  Currently, I can issue a 
URLAUTH for:
  1) a specific user on my system
  2) the authorized submission entity.

I would like to be able to issue a URLAUTH for anyone at my organization 
(the authuser case), rather than having to issue a separate URLAUTH for 
each person.

I would like to be able to issue a URLAUTH for someone not at my 
organization (the anonymous case) who otherwise has no access to my 
server.

There are safeguards:
  a) I can set an expiration date/time on the URLAUTH.
  b) I can revoke the URLAUTH at any time.
  c) Site policy has to permit anonymous access, so if I work at The Very
     Paranoid Corporation an anonymous URLAUTH is useless since TVPC does
     not allow anonymous authentication to their IMAP server (I don't think
     that any IMAP server allows anonymous by default).

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.