Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] Self-describing data

Expand Messages
  • S. Alexander Jacobson
    With all due respect, the signing/court issue is a red-herring. In real life, I have a http://universalcard.com credit card. When I log in (via a web form), I
    Message 1 of 55 , Jul 3, 2003
    • 0 Attachment
      With all due respect, the signing/court issue is a
      red-herring.

      In real life, I have a http://universalcard.com
      credit card. When I log in (via a web form), I
      arrive at the homepage for my account:

      https://www.accountonline.com/AccountSummary

      This page has my current balance, available
      credit, last payment made, and last payment date,
      among other information. There is also a link on
      that page to:

      https://www.accountonline.com/AccountSummary?PRINT_VERSION=Y

      I can also link to a printable version of my
      unbilled transactions:

      https://www.accountonline.com/UnbilledTrans?PRINT_VERSION=Y

      Both printable versions are simply current records
      of my account state without any links/buttons to
      make changes.

      I'd like to be able to provide third parties
      (e.g. my accountant) with access to these pages,
      but I can't without providing them with control
      over my entire account.

      The questions are:
      1. Is this system RESTful?
      2. Would it be RESTful if it used HTTP-auth rather than cookie auth?

      -Alex-

      ___________________________________________________________________
      S. Alexander Jacobson i2x Media
      1-212-787-1914 voice 1-603-288-1280 fax




      On Thu, 3 Jul 2003, Mark Baker wrote:

      > The relevant test here is, I believe, whether the state of the resource
      > is relevant to the meaning of the message/data, or whether its identity
      > is all that is relevant. This is a key part of the "self-describing"
      > umbrella. As an example, if you were a party to the court action, then
      > your identity (via your name) on some document is likely relevant. But
      > the colour of your hair probably wouldn't be (as an example of what
      > might be returned from GET on my URI).
      >
      > In Paul's example there, if the state of the resource was important,
      > even if it was believed static, it should have been included in the
      > court documents by value rather than by reference.
      >
      > MB
      >
      > On Thu, Jul 03, 2003 at 06:17:46PM -0700, Paul Prescod wrote:
      > > Walden Mathews wrote:
      > > > Paul,
      > > >
      > > > I buy all that, and yet I still have an issue with Tyler's example
      > > > of the bank account URI that identifies anyone's account at that
      > > > bank, depending on who's fired up their user agent. To me, the
      > > > account (identified by the bank sure enough with its own number)
      > > > has identity that transcends the clever "my account" resource,
      > > > and the legal system is going to be more interested in the former
      > > > than the latter, if issues arise. Identity is tricky business.
      > > > ...
      > > > If the person sitting to my left pilfers from my bank account, I want
      > > > the identity of both to be irrefutable, so I guess I won't be dragging
      > > > any URI into court.
      > >
      > > Yes, it seems clear to me that one needs to drag _digitally signed
      > > messages_ into courts. Let's say you have a very precise (specific) and
      > > URI for a single transaction with a single invariant representation.
      > > Then you go to court and you notice that the transaction has changed.
      > > The interface said it was invariant but the scoundrels have changed it
      > > in the database. You'll be out of luck unless you saved a digitally
      > > signed message with the old value.
      > >
      > > Paul Prescod
      > >
      > >
      > >
      > >
      > >
      > > To unsubscribe from this group, send an email to:
      > > rest-discuss-unsubscribe@yahoogroups.com
      > >
      > >
      > >
      > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      > --
      > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
      >
      >
      > To unsubscribe from this group, send an email to:
      > rest-discuss-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
    • Alex Jacobson
      The only thing that a proxy decides based on the content of the auth headers is caching and if you do cookie-auth you just do more explicit cache-control. And
      Message 55 of 55 , Jul 25, 2003
      • 0 Attachment
        The only thing that a proxy decides based on the content of the auth
        headers is caching and if you do cookie-auth you just do more explicit
        cache-control. And if you are doing auth-related stuff, you should be
        doing more explicit cache control anyway so I don't see the value that
        special purpose auth headers provide.

        -Alex-


        ___________________________________________________________________
        S. Alexander Jacobson i2x Media
        1-212-787-1914 voice 1-603-288-1280 fax

        --On Thursday, July 24, 2003 11:17 PM -0400 Chuck Hinson
        <cmhinson@...> wrote:

        >
        >
        > S. Alexander Jacobson wrote:
        >
        >> cookie-based and HTTP auth are identical when the
        >> client is software. The only difference is the
        >> name of the HTTP header in which the
        >> authentication token is passed. But really the
        >> whole premise of HTTP auth is unreasonable for
        >> automated clients. Clients just send a secret
        >> token. They don't need a mnemonic separating
        >> usernames from passwords.
        >>
        >> For human users, the login form that comes in the
        >> 401 response is as visible as you want. In
        >> practice Mozilla appears to auto-fill most login
        >> forms I reach correctly and without issue which
        >> makes me think that visibility is a non-issue.
        >>
        >> -Alex-
        >>
        >>
        >>
        > Hmmm. I thought visibility was about the ability of
        > components/intermediaries to understand the meaning of the message.
        > I.e., a proxy can't tell whether or not a cookie contains auth info
        > since it doesnt know the syntax of what's been packed in the cookie.
        > However, it does know what the HTTP auth header means, and thus knows
        > what it can or cant do with the message (and its response). (This all
        > may be moot as far as auth headers and cookies go since I think many
        > proxies wont cache things with cookies in them).
        >
        > --Chuck
        >
        >> On Thu, 24 Jul 2003, Chuck Hinson wrote:
        >>
        >>
        >>
        >>> Alex Jacobson wrote:
        >>>
        >>>
        >>>
        >>>> --On Wednesday, July 23, 2003 2:53 PM -0700 "Roy T. Fielding"
        >>>> <fielding@...> wrote:
        >>>>
        >>>>
        >>>>
        >>>>
        >>>>> You should note that there is no design reason why Authorization
        >>>>> and WWW-Authenticate are limited to Basic and Digest. That is why
        >>>>> those fields are extensible. Why would you want to duplicate that
        >>>>> functionality in another field?
        >>>>>
        >>>>>
        >>>>>
        >>>>>
        >>>> With all due respect, given that HTTP authentication is fundamentally
        >>>> broken*, that cookies are a defacto standard, and that HTTP-auth is
        >>>> poorly supported by actual UAs. The bigger question is why duplicate
        >>>> cookie functionality with auth-specific headers?
        >>>>
        >>>>
        >>>>
        >>>>
        >>> I would think that while cookies may be a defacto standard, cookie-based
        >>> authentication is not (i.e., there is no standard implementation of
        >>> authentication using cookies). Thus, it would seem to me that
        >>> visibility still suffers.
        >>>
        >>> --Chuck
        >>>
        >>>
        >>>
        >>>
        >>
        >>
        >>
        >>
        >
        >
        >
        > To unsubscribe from this group, send an email to:
        > rest-discuss-unsubscribe@yahoogroups.com
        >
        >
        >
        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.