Hi friends..
  now a days i m faceing a problem related to webservice in asp.net.
actually i have to create a webservice and client will interact that
service through REST.
  so anyone know about that plz help me bcoz i stucked by this problem
from last one week.i have search lots but i got only about SOAP.
if any one know about it so plz tell me..how to use that one through
HTTp get method..

Thanks

Bye

Quoting Walden Mathews <waldenm@...>:

> | | WSDL+SOAP is very attractive because of its ability to generate
> | | client stubs in many languages: Java,C++, etc.

It's being a vote for WSDL+SOAP is a reason to discuss it, and that discussion
may possibly go back into rest-explore rather than rest-discuss matters (*if*
we
should compete in creating proxy stubs as WSDL+SOAP can then that might be
quite a challenge).

WSDL hides the network though, its raison d'ętre is to hide the network. If we
believe that hiding the network is a Bad Thing (one of the arguments of *some*
people evangelising REST is that it doesn't hide it) then we have to conclude
that WSDL is a Bad Thing. The description of "very attractive" is quite apropos
therefore because hiding the network is very attractive; as are all
anti-patterns.

On the other hand, just because we shouldn't hide it, do we need to look at it
all the time? We don't want every piece of code that calls into a REST service
to be primarily dealing in networking details, do we? (And if we do, to what
extent - do I really want to know I received a 304 instead of a 200, or just
invisibly benefit from the inherent performance gain).

Of course, since using a REST service tends to be simpler than using a SOAP
service (in and of themselves, before we add differences in tool support to the
mix) there is less need for wrapping and hiding of the type WSDL uses.
As long as I can do some sort of HTTP with whatever I'm using to develop I can
quickly use a REST service - and build whatever degree of abstraction into this
that seems appropriate for the task in hand.

With the stock ticker that seems to be the "hello world" of web services I just
need to concatenate the stock symbol to the service URI and do a simple search
on the returned data. With a more complicated service I'd probably want to
remarshall into some sort of OOP or Generic+OOP equivalent - but then I might
very well want to re-wrap the model of a more RPC-style service to better match
how I use it anyway.

More complicated services gain the most from WSDL. But these services generally
still require a relatively large degree of orientation to start using. While
some are saying that this will be reduced or removed by a layer on top of WSDL
(and on top of that, and on top of that) in the meantime this is still very
important. If this part of the complexity grows faster than the part of the
complexity removed by WSDL then the overall comparison still favours REST over
SOAP+WSDL.

On balance REST+WSDL seems inferior to REST to me right now.

--
Jon Hanna
<http://www.hackcraft.net/>
"…it has been truly said that hackers have even more words for
equipment failures than Yiddish has for obnoxious people." - jargon.txt

This is more of a rest-discuss question...should be continued
there.


----- Original Message -----
From: "zipf5r" <Klimov1@...>
To: <rest-explore@yahoogroups.com>
Sent: Friday, March 26, 2004 9:35 AM
Subject: [rest-explore] Newbie question


| Who can clarify me: can I use WSDL to describe non-SOAP Web Service?
| WSDL+SOAP is very attractive because of its ability to generate
| client stubs in many languages: Java,C++, etc.
| But WSDL+REST...isn't???
| Any help would be very appreciated.
| Andrew
|
|
|
|
| Yahoo! Groups Links
|
|
|
|
|
|
| __________ NOD32 1.694 (20040326) Information __________
|
| This message was checked by NOD32 antivirus system.
| http://www.nod32.com
|
|

Who can clarify me: can I use WSDL to describe non-SOAP Web Service?
WSDL+SOAP is very attractive because of its ability to generate
client stubs in many languages: Java,C++, etc.
But WSDL+REST...isn't???
Any help would be very appreciated.
Andrew

(The following is a broad overview of a system I am developing; I think it
is right exactly up the alley of REST, though it proposes to transcend some
parts of the REST architectural setup, without violating its motivations.
Two brief "appendices" quickly describe the relationship between this model
and RDF, and REST.  -- Seth Johnson)


Context Transfer Protocol

The context transfer protocol (CTP) is an end-to-end data transport protocol
that supports manipulable distributed hypermedia and data processing on the
basis of the concept of universal state transfer.  It employs a set of
abstract terms that designate the elements of a uniform structure for
representing and transferring state, called the uniform context framework
(UCF).

In place of documents and files, CTP implements contexts, manipulable
collections of resource elements which are referred to according to the UCF
abstractions.  All of the elements of a context are assigned key values
which function as links to the servers at which the elements originate.
Because all elements are links, multiple contexts may freely reuse the same
elements.

The elements of the UCF reflect a universal information architecture which
supports all the fundamental operations one needs for managing information,
including modeling, updating and maintenance, manipulation, querying,
categorizing, distribution and dependency tracking.  In this way, CTP
implements the notion of an atomic application.  Fundamental information
processing functions for any application can be implemented simply by
declaring a CTP context, or by declaring multiple contexts to be combined in
a complex application.  Any CTP front end interface that surfaces the full
complement of CTP functionality can be used to browse and work with any
information for any other application served by a CTP server.

CTP is designed for scalability, providing a simple uniform interface
through the use of a small set of verbs (GET, PUT, REMOVE and HOST) and the
finite set of generic elements which make up the UCF.  CTP servers attain
the status of universal application servers in the sense that all
fundamental information management functions are provided by means of this
interface and the rest of the functions and architecture incorporated within
the protocol.

The information architecture underlying CTP affords a maximum degree of
flexibility in data processing.  Entity relationships for all applications
are stored in a flat fact table form, allowing information to be accessed
and worked with rapidly, flexibly and with implicit interoperability among
all applications.  In addition, by using the UCF abstractions as generic
primitives, CTP makes possible a highly granular procedural approach to data
processing that is unimpeded by the intricacies of entity-relationship
models or the strictures of table- or record-level distribution and/or
replication.  Higher-level techniques for managing complexity, such as
set-oriented and object-oriented data processing and programming, may be
implemented on top of the CTP layer.

Instead of working with information through the representation of diverse
entities in separate physical tables, the CTP physical data model is a
generalized and denormalized structure that directly represents relations as
such.  Relations implemented under CTP are called contexts.  CTP uses the
following generic abstractions to represent the elements of any context:

  * Space
  * Location
  * Standpoint
  * Use Type
  * Use
  * Link Type
  * Link
  * Use Attribute
  * Link Attribute
  * Use Attribute Value
  * Link Attribute Value
  * Use Category
  * Link Category
  * Use Category Value
  * Link Category Value

These elements make up the uniform context framework (UCF), a standard
structure for representing and transferring state.  CTP assigns unique key
values to each element, made up of a URL (designating the location of a CTP
server), a forward slash, and a key value unique to that server.  For
example: ctphome.org/18273645.

A general context in CTP is comprised of a use type related to a link type.
A particular context instance is designated by a particular use of the use
type, which can have any number of links, particular instances of the link
type, related to it.  This combination of use types, link types, uses, and
links describes a traditional one-to-many relationship, wherein the various
uses of a use type serve as “records” of the parent entity type (on the
“one” side), and the multiple links of a link type serve as “records” of the
child entity type (on the “many” side).

In CTP, state is an aspect of contexts representing their generality, and is
designated in terms of the concepts of space, location, and standpoint.
Declaring a state for a CTP context means that the context serves as a
convention among all clients and servers that participate in that state.
Space represents the notion of an abstract realm within which numerous CTP
servers participate and interoperate as they support shared contexts.
Location represents an individual CTP server.  Standpoint is an abstraction
used to represent states of narrow scope hosted at particular locations, for
the purpose of independent or provisional development work.

Generality of a state is designated by either providing key values for
space, location and/or standpoint, or leaving their key values empty.  A
state representing generality across an entire space is represented by
providing a unique key value for the space, while leaving the location and
standpoint keys empty.

A state for representing universal conventions would be designated by
leaving all three key values empty.  However, since this designates no
authoritative server for the state, contexts defined within such a state
cannot be managed by CTP, and would require ratification as standards by
external standards bodies, followed by general adoption in code and
practice.  With CTP, this process of fostering general adoption by means of
standards bodies becomes significantly less necessary.  Instead of
presupposing that state and physical data models are so arbitrarily complex
and diverse as to necessitate such a process in order to assure
interoperability, CTP provides for universal interoperability at the data
transport level.

Traditional entity-relationship modeling entails record- and table-level
replication in distributed environments because it binds sets of attributes
to individual physical tables representing discrete entities.  Under CTP,
distribution of attributes and their values is not accomplished in the same
manner.  CTP uses the UCF to distribute metadata describing the relational
organization of information across servers, while it leaves particular
attribute values at particular locations, where CTP servers act as their
authoritative hosts.  User agents and interoperating CTP servers may
maintain the currency of their local caches of attribute values according to
any algorithm appropriate to their own purposes.

Instead of binding sets of attributes to particular tables representing
particular entities, CTP uses the abstractions that make up the UCF to
describe scopes of relevance for link and use attributes.  Attributes can be
declared to be relevant for all links of a particular link type, or for all
links used by a particular use type, or for all instances of a particular
use or link regardless of general context (use type and/or link type), or
for any other of the finite number of scopes that can be described by the
possible permutations of the UCF elements.  CTP servers provide and maintain
appropriate attributes and values for various contexts according to these
scopes of relevance.

CTP contexts do not presuppose or require locking mechanisms, since whenever
user agents request an occasion to modify a context, CTP servers notify them
whether the context has been modified in whole or in part since the time of
the user agent's local copy.  CTP servers may implement shared contexts as
freely interruptible or as "reservable" according to diverse governing
principles.  Separate protocols may implement locking or other "reservation"
schemes on top of the CTP layer, for contexts for which that is desired.

Message structure
	 - requests, responses, occasions, events

State distribution system
	 - metadata, attributes, values, hosts

Data structure
	 - denormalized

Errors / Responses

Appendix A: CTP and RDF

The correlates for RDF's subjects, predicates, and objects under CTP are
uses, link types, and links.

CTP/Use - Rdf Subject
CTP/Link Type - Rdf Predicate
CTP/Link - Rdf Object

CTP moves beyond RDF's knowledge-modeling assertions by splitting subjects
into use types and uses, and then using the combination of use types with
link types to define atomic applications, contexts which automatically
provide all fundamental information functions needed to manage information
for any application.  Because CTP is designed in this manner, it is
perfectly suited for RDF applications.  It simply goes beyond the
knowledge-modeling purposes of RDF and the semantic web, to providing
universal fundamental functions and implicit interoperability among all
applications.

Appendix B: CTP and REST

Roy Fielding has articulated a comprehensive set of engineering principles
which constitute an architectural style called "representational state
transfer" (REST) intended to govern optimal Web architecture and Web
application design.  By describing how CTP's implementation of universal
state transfer compares with the architectural principles of REST, we can
address its design implications in an orderly and reasonably complete
manner.  The chief differences stem from the fact that past architectural
principles have presupposed the arbitrary complexity of state and data
models, and therefore have taken certain design decisions geared toward
managing complexity, which are unnecessary within CTP.


--

DRM is Theft!  We are the Stakeholders!

New Yorkers for Fair Use
http://www.nyfairuse.org

[CC] Counter-copyright: http://realmeasures.dyndns.org/cc

I reserve no rights restricting copying, modification or distribution of
this incidentally recorded communication.  Original authorship should be
attributed reasonably, but only so far as such an expectation might hold for
usual practice in ordinary social discourse to which one holds no claim of
exclusive rights.

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the rest-explore
group.

   File        : /Click here for a great dating service
   Uploaded by : libohenolu7135 <libohenolu7135@...>
   Description : Browse through singles

You can access this file at the URL

http://groups.yahoo.com/group/rest-explore/files/Click%20here%20for%20a%20great%\
20dating%20service

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

libohenolu7135 <libohenolu7135@...>

Excellent Dating Site Exclusively for Military singles And Their
Admirers.


Http://www.militaryfriends.com/i/4

> > For example, this recently came up on the CSS list, when Andrew McFarland
> > pointed out that in his name the "c" in "Mc" should be superscript:
>
> So how has he survived using e-mail all these years?

Touche! I don't really have a specific must-have example of using markup
in those elements, it's more of a nagging feeling that being able to do so
presents opportunities for smart software.

However as you point out, the RDFish metadata approach also allows nesting
arbitrary markup, so it's not like such a gulf between the two approaches.

> The <subject> element may contain mixed content.  However, if an application
> processing <subject> does not know how to handle contained elements, those
> elements will be ignored while the PCDATA within them will still be
> processed.  The choice of which vocabulary is used within <subject> should
> take this behavior into account for greater compatibility.

Hmm, more or less, although I probably wouldn't have expressed it like
that. It's really just using XML as markup, where you care about the
*text*, rather than some hierarchical structure, and the elements and
attributes are really incidental to the text that you are presenting.

A good test for whether XML is being used as markup or for hierarchical
structure is to imagine the tags disappearing, and seeing if the resulting
text still makes sense. (XHTML is definitely on the markup side of the
spectrum, while vocabularies that store all data in attributes of empty
elements and eschew mixed content altogether are not).

Michael Day

--
YesLogic Prince prints XML!
http://yeslogic.com/prince

From: "Michael Day" <mikeday@...>
>
> > In its place, I have tentatively added a "version" attribute...
>
> Is it optional? :)
>
> > Hmm...  Yes, it would probably be a good idea.  I'll have to work on
that
> > one ("infoset... *blech*").
>
> Well, the other alternative would be to *not* require a whole document
> comparison, if all you really care about are the two identity and inbox
> URIs. That way the software could just store the URIs rather than worrying
> about storing the entire documents, and just compare the URIs with those
> in the document that comes back. Avoids the quagmire of normalisation,
> canonicalisation and augmented frankinfoset comparison :)

Yeah, that's all I really want (at least for the inboxAgreement).

> However on the subject of normalisation... comparing two URIs is not
> exactly straightforward either.

True.  Maybe the TAG will finally come up with something to work with.
However, since there are only two entities involved in the creation of the
document, I may be able to say that the values of the URI attributes are not
alterable once added to inboxAgreement, which means the comparisons can be
done on at the character level.  If an entity decides to alter such a value
(even if the altered URI resolves to the same resource) and the other entity
rejects the document as a result, so be it.

> > Yes, almost all of the elements allow optional content.  However, they
do
> > not allow mixed content.  They must be elements only. So instead, you
could
> > have:
> >
> > <to uri="mailto:mikeday@...">
> >     <ns:commonName>Michael Day</ns:commonName>
> > </to>
>
> Okay, so in RDF terms the children of the from/to/cc elements are
> predicates that relate to the uri given in the attribute...

Yes, that would be an accurate statement.  However, there are no
restrictions on what can be within those elements.  Mixed content, PCDATA
only, etc.

> > On the other hand, if you are just suggesting the ability to put a
plaintext
> > name in for <from>, <to>, and <cc>, I'd be more inclined to add a "name"
(or
> > some such) attribute:
> >
> > <to uri="mailto:mikeday@..." name="Michael Day" />
>
> Okay, now I'm torn between your proposal for infinitely extensible
> metadata, RDF-style, or a more XMLish approach of allowing mixed content
> and arbitrary markup inside the element, which could of course still have
> metadata in attributes.

Well, i am still of the mind to go the pseudo-RDF route, where elements can
contain only elements relating to the URI, but that those elements can
contain anything they want.  For instance, if someone wanted to add xhtml,
they would need to use something like <xhtml:body>.

As for the "name" attribute above, I am just suggesting to add that as part
of the RNA spec.  On the other hand, I could add an optional child element
<name> which could contain mixed content.  The rules for application
processing would be the same as the <subject> element (see below).

> For example, this recently came up on the CSS list, when Andrew McFarland
> pointed out that in his name the "c" in "Mc" should be superscript:
>
> <to uri="..."> Andrew M<sup>c</sup>Farland </to>

So how has he survived using e-mail all these years?

> And the i18n guys are putting strong pressure on the XHTML working groups
> to use element content rather than attributes for human readable text.
>
> I suppose it needs some more thought. Perhaps there are some cooler things
> that can be done with the RDF-style metadata, I don't know.

Yes, I agree.  More pondering would be good.

> > I'm not sure I'll budge on this one.  Allowing <subject> to contain
markup
> > feels like opening a pandora's box to me.  Further, it can greatly
> > complicate user interfaces to be able to support <subject>.  In all of
the
> > other elements, additional content can be optionally ignored (see
> > extension), but I think it would be hard to effectively ignore markup
inside
> > <subject> and still keep subject useful...
>
> Markup can be ignored simply by taking the text and ignoring the tags, so
> it needn't complicate any user interface that doesn't want to deal with
> it. For example:
>
> <subject> Hey, today is <strong>your birthday!</strong> </subject>
>
> which may be rendered with appropriate bold fonts in a graphical user
> interface, could easily be rendered "Hey, today is your birthday!" in Lynx
> or Pine or a mobile phone or any other text based interface.

So what you suggest is something like:

The <subject> element may contain mixed content.  However, if an application
processing <subject> does not know how to handle contained elements, those
elements will be ignored while the PCDATA within them will still be
processed.  The choice of which vocabulary is used within <subject> should
take this behavior into account for greater compatibility.

---
Seairth Jacobs
seairth@...

> In its place, I have tentatively added a "version" attribute...

Is it optional? :)

> Hmm...  Yes, it would probably be a good idea.  I'll have to work on that
> one ("infoset... *blech*").

Well, the other alternative would be to *not* require a whole document
comparison, if all you really care about are the two identity and inbox
URIs. That way the software could just store the URIs rather than worrying
about storing the entire documents, and just compare the URIs with those
in the document that comes back. Avoids the quagmire of normalisation,
canonicalisation and augmented frankinfoset comparison :)

However on the subject of normalisation... comparing two URIs is not
exactly straightforward either.

> 1) It provides a recognizable "signature"
> 2) It solves the problem of a container for multiple <notification> elements

Yes, the rna element seems to fit quite nicely. It's short, too.

> Yes, almost all of the elements allow optional content.  However, they do
> not allow mixed content.  They must be elements only. So instead, you could
> have:
>
> <to uri="mailto:mikeday@...">
>     <ns:commonName>Michael Day</ns:commonName>
> </to>

Okay, so in RDF terms the children of the from/to/cc elements are
predicates that relate to the uri given in the attribute...

> On the other hand, if you are just suggesting the ability to put a plaintext
> name in for <from>, <to>, and <cc>, I'd be more inclined to add a "name" (or
> some such) attribute:
>
> <to uri="mailto:mikeday@..." name="Michael Day" />

Okay, now I'm torn between your proposal for infinitely extensible
metadata, RDF-style, or a more XMLish approach of allowing mixed content
and arbitrary markup inside the element, which could of course still have
metadata in attributes.

For example, this recently came up on the CSS list, when Andrew McFarland
pointed out that in his name the "c" in "Mc" should be superscript:

<to uri="..."> Andrew M<sup>c</sup>Farland </to>

And the i18n guys are putting strong pressure on the XHTML working groups
to use element content rather than attributes for human readable text.

I suppose it needs some more thought. Perhaps there are some cooler things
that can be done with the RDF-style metadata, I don't know.

> I'm not sure I'll budge on this one.  Allowing <subject> to contain markup
> feels like opening a pandora's box to me.  Further, it can greatly
> complicate user interfaces to be able to support <subject>.  In all of the
> other elements, additional content can be optionally ignored (see
> extension), but I think it would be hard to effectively ignore markup inside
> <subject> and still keep subject useful...

Markup can be ignored simply by taking the text and ignoring the tags, so
it needn't complicate any user interface that doesn't want to deal with
it. For example:

<subject> Hey, today is <strong>your birthday!</strong> </subject>

which may be rendered with appropriate bold fonts in a graphical user
interface, could easily be rendered "Hey, today is your birthday!" in Lynx
or Pine or a mobile phone or any other text based interface.

> That's not entirely true.  A client does not know which authentication
> scheme it will need to use until the server tells it.  As a result, sending
> in user:pwd according to the basic authentication scheme will do little good
> if the server is expecting to use digest authentication.

That's true! I'd forgotten that entirely, and there is no hint in the URI
of which scheme to use either.

> Having said all that, I will be uploading the new version shortly.  I want
> to add some additional text and see if there are still more places that need
> cleaning up...

Great :)

Michael Day

--
YesLogic Prince prints XML!
http://yeslogic.com/prince

From: "Michael Day" <mikeday@...>
>
> Perhaps "contains the URI of a resource" rather than *to* a resource, and
> "sent to the intended recipients." rather than a single recipient URI, and
> uses the information "to retrieve a representation of the resource", which
> is extremely picky but I think necessary for true REST credibility.

I have cleaned this up a bit...

> You describe an advantage that both the sender of the notification and the
> resource itself must be identifiable by a URI, but the introduction quoted
> above says nothing about the *sender* being identified, only the resource
> itself and the recipients. It then goes on to say that this disallows the
> possibility of retrieval of a notification from someone other than the
> claimed sender, but again the introduction does not describe notifications
> being retrieved, only sent.

Sorry.  This was an artifact from when the <query> element was in there.
Since that's gone, the associate bullet need to go too.

> The distinction between Identity and Inbox URIs is very clear :)

Thanks.  I tried.  :)  Even Tyler should be satisfied.  <g>

> There appears to be a partial sentence "By assigning Inbox URIs instead of
> using each party's Identity URI."

Oops.  Removed.  I also clean up some of the wording in that area...

> I think using the RNA namespace URI for versioning needs careful thought,
> as bumping up the version can break deployed software that expected a
> particular namespace, even when the meaning of the elements has not
> changed.

As per the other conversation (Namespaces in RNA), the namespace stuff has
been entirely removed for now (with the exception of the Extension section).
I have to admit that I have never been too fond of namespaces and would be
just as happy as could be if RNA could avoid them to some extent.  :)

In its place, I have tentatively added a "version" attribute...

> Also, areas of the spec that describe returning the same document and
> comparing documents with each other need to be clear on what basis they
> are compared; for example at the byte, character, or infoset level.

Hmm...  Yes, it would probably be a good idea.  I'll have to work on that
one ("infoset... *blech*").

> Is there a good reason for wrapping notification and inboxAgreement in an
> rna element? Is the content model for the rna element like this:
>
> rna: inboxAgreement | notification+

Yes, that is correct.  I have reworked that section to make the statement
more obvious.  As for the root element:

1) It provides a recognizable "signature"
2) It solves the problem of a container for multiple <notification> elements

> The from, to, and cc elements should not be empty, they should be allowed
> to contain optional text and markup, such as:
>
> <to uri="mailto:mikeday@..."> Michael Day </to>
>
> (Perhaps you have already covered this, as you state that it may contain
> additional metadata elements within it that relate to the sender).

Yes, almost all of the elements allow optional content.  However, they do
not allow mixed content.  They must be elements only. So instead, you could
have:

<to uri="mailto:mikeday@...">
     <ns:commonName>Michael Day</ns:commonName>
</to>

On the other hand, if you are just suggesting the ability to put a plaintext
name in for <from>, <to>, and <cc>, I'd be more inclined to add a "name" (or
some such) attribute:

<to uri="mailto:mikeday@..." name="Michael Day" />

> I think the subject should be allowed to contain markup, not necessarily
> just text. This has value for all the things that text cannot express,
> such as ruby, subscripts and superscripts and who knows what. Yes, people
> could use this to include an entire message in the subject. But such
> people could do equally stupid things in other ways :)

I'm not sure I'll budge on this one.  Allowing <subject> to contain markup
feels like opening a pandora's box to me.  Further, it can greatly
complicate user interfaces to be able to support <subject>.  In all of the
other elements, additional content can be optionally ignored (see
extension), but I think it would be hard to effectively ignore markup inside
<subject> and still keep subject useful...

> If you say "nonce", please define what it means for those who don't know.

I've taken out "nonce" and replaced it with "unique key".  It was an
incorrect usage anyhow (since "nonce" is related to time).

> In Example 10: Protected Resource, you describe Bob as being confronted
> with a 401 response. However it's quite likely that his software would
> submit the authentication tokens with the first request, as it already
> knows that they are required. This avoids unnecessary round trips.
>
> (A common misconception of HTTP Authentication people bring up is that it
> doubles the number of requests, when in fact it generally only doubles the
> first request, and not necessarily even that if you expect that
> authentication will be required).

That's not entirely true.  A client does not know which authentication
scheme it will need to use until the server tells it.  As a result, sending
in user:pwd according to the basic authentication scheme will do little good
if the server is expecting to use digest authentication.



Having said all that, I will be uploading the new version shortly.  I want
to add some additional text and see if there are still more places that need
cleaning up...

---
Seairth Jacobs
seairth@...

> Hmm... so, in a nutshell:  no namespace for RNA, but require any other
> vocabulary that's used within RNA to be namespaced?  In a way, that makes
> sense.  I do not forsee RNA being embedded inside other documents... hmm...

Not to mention that if you stick with the current elements, the root
element of "rna" is a pretty clear indication of what the document is.

Michael Day

--
YesLogic Prince prints XML!
http://yeslogic.com/prince

From: "Michael Day" <mikeday@...>
>
> In summary, I think the RNA elements should be used without a namespace,
> unless there is a very compelling reason.

Hmm... so, in a nutshell:  no namespace for RNA, but require any other
vocabulary that's used within RNA to be namespaced?  In a way, that makes
sense.  I do not forsee RNA being embedded inside other documents... hmm...

---
Seairth Jacobs
seairth@...

Hi Seairth,

This is a specific point relating to the use of the RNA namespace.

I believe that the RNA elements should only be placed in a namespace if
there is a compelling reason to do so, that brings clear benefits to the
use of RNA. Otherwise, the elements should be left without a namespace.

Here are several examples of XML specifications, each of which use
namespaces differently to suit their needs.

Example 1: XSLT

XSLT elements are placed in a namespace to distinguish them from the
output elements in the transform. Thus <xsl:if> is a directive to the
transformer, while <if> in another namespace or in no namespace is a
literal element for output.

The use of a namespace in XSLT is clearly necessary, even though it does
lead to complicated outcomes in the case of XSLT transforms that seek to
transform or emit other XSLT transforms, but such a use case is probably
going to be complicated whichever approach is taken.

Example 2: XHTML

XHTML elements are placed in a namespace so that they may be used within
other document types and still recognised as being XHTML. This is a much
weaker justification, as the overwhelming majority of XHTML uses are
likely to be in standalone documents where the namespace is irrelevant.

This is borne out by the fact that XHTML elements are rarely explicitly
qualified (<p> is better than <h:p> or <html:p>) and often the namespace
declaration itself is omitted, thanks to the glorious hack of DTD FIXED
attributes. Mixed namespace documents may still be created of course, by
including elements in other namespaces even if the XHTML elements are left
unqualified.

Example 3: XML-RPC

XML-RPC elements are not placed in a namespace, as there is no benefit for
this to be done. They are not nested within arbitrary document types, and
there is no complicated disambiguation requirement as with XSLT. Adding a
namespace in this situation would merely increase the size of the
documents, increase the possible syntactic variations and make processing
them more fragile and require more complicated code.

The use of a namespace for versioning is quite suboptimal, and it's worth
pointing out that XSLT, the most namespace heavy of the three examples,
has a separate version attribute that it uses for this purpose. Such an
attribute is much easier for implementations to parse and much clearer as
to its intent. This also has the benefit of not changing the namespace
unnecessarily, such as when new elements are added but the semantics of
existing elements remain unchanged.

Note that the use or non-use of an RNA namespace does not impact the use
or non-use of other namespaces, such as the Dublin Core namespace for
disambiguating other elements in the notification.

In summary, I think the RNA elements should be used without a namespace,
unless there is a very compelling reason.

Michael Day

--
YesLogic Prince prints XML!
http://yeslogic.com/prince

Hi Seairth,

Nice work :) Here are some rather picky comments, starting with the
introduction:

> A "notification" is created that contains a URI to a resource, as well
> as some additional metadata about the notification (and possibly the
> resource itself). The notification is then sent to the intended
> recipient URI.  The recipient then examines the notification and uses
> the information to retrieve the resource.

Perhaps "contains the URI of a resource" rather than *to* a resource, and
"sent to the intended recipients." rather than a single recipient URI, and
uses the information "to retrieve a representation of the resource", which
is extremely picky but I think necessary for true REST credibility.

You describe an advantage that both the sender of the notification and the
resource itself must be identifiable by a URI, but the introduction quoted
above says nothing about the *sender* being identified, only the resource
itself and the recipients. It then goes on to say that this disallows the
possibility of retrieval of a notification from someone other than the
claimed sender, but again the introduction does not describe notifications
being retrieved, only sent.

The distinction between Identity and Inbox URIs is very clear :)

There appears to be a partial sentence "By assigning Inbox URIs instead of
using each party's Identity URI."

I think using the RNA namespace URI for versioning needs careful thought,
as bumping up the version can break deployed software that expected a
particular namespace, even when the meaning of the elements has not
changed.

Also, areas of the spec that describe returning the same document and
comparing documents with each other need to be clear on what basis they
are compared; for example at the byte, character, or infoset level.

Is there a good reason for wrapping notification and inboxAgreement in an
rna element? Is the content model for the rna element like this:

rna: inboxAgreement | notification+

The from, to, and cc elements should not be empty, they should be allowed
to contain optional text and markup, such as:

	 <to uri="mailto:mikeday@..."> Michael Day </to>

(Perhaps you have already covered this, as you state that it may contain
additional metadata elements within it that relate to the sender).

I think the subject should be allowed to contain markup, not necessarily
just text. This has value for all the things that text cannot express,
such as ruby, subscripts and superscripts and who knows what. Yes, people
could use this to include an entire message in the subject. But such
people could do equally stupid things in other ways :)

If you say "nonce", please define what it means for those who don't know.

In Example 10: Protected Resource, you describe Bob as being confronted
with a 401 response. However it's quite likely that his software would
submit the authentication tokens with the first request, as it already
knows that they are required. This avoids unnecessary round trips.

(A common misconception of HTTP Authentication people bring up is that it
doubles the number of requests, when in fact it generally only doubles the
first request, and not necessarily even that if you expect that
authentication will be required).

By the way, that's a very restrictive license down the bottom. No right to
create modifications or derivatives? And the authorship attribution in
implementing software is vague and scary. What if your software uses a
library that implements RNA? Is the attribution requirement transitive?
I think a less alarming license might be worth considering.

Michael Day

--
YesLogic Prince prints XML!
http://yeslogic.com/prince

After much discussion and much thought, I have done a major rewrite of the
RNA draft document.  I think this new version is significantly better than
the prior one and adds a whole level of sophistication without any
additional complication. It is now quite a bit more informative and possibly
easier to understand, as well.  Some *major* changes have been made, so
anyone who has already read the first draft, re-read this one.

The document is available at:

PURL : http://purl.org/rna/draft
URL  : http://www.seairth.com/web/rna/


I'm looking for feedback!  So... let me hear it!  Happy weekend reading.
<g>

---
Seairth Jacobs
seairth@...

----- Original Message -----
From: "Seairth Jacobs" <seairth@...>

> However, the recipient doesn't really
> have a way to *know* that the POSTed representation belongs to the
resource
> at http://seairth.com/rna/234 unless the recipient turns around and GETs
the
> representation from that URI.  So then we are back to the question of "why
> push a representation?".
How about associating Authentication information in the POST request with
the authority of the indicated URI - meaning use something that verifies the
request as coming from search.com.
The assumption being that the host controls all URI within it.

From: "Michael Day" <mikeday@...>
>
> > You will notice that Phase 2 is pretty much the same in all three cases.
> > The only difference is who passes a capability URI in Phase 1.  So...
what
> > do you all think?  Does this work?  Is it RESTful?  Is there a better
way?
>
> Hmm, I may need to re-read this a dozen times first to make sure I
> understand who is posting what to whom. I find it difficult to map the
> examples that you gave to the idea of sending someone an email, which was
> much easier to see in the earlier versions.


In the various cases (depending on which capability URIs are sent to whom):

     The user at http://seairth.com/rna would send notifications to
http://rnaserv.net/bob via http://rnaserv.net/bob/44953324.
     The user at http://rnaserv.net/bob would send notifications to
http://seairth.com/rna via http://seairth.com/rna/12345.

Here's a re-wording of the solutions that may make it easier to read:

---

Solution To Pattern #1:

Phase 1: I POST http://seairth.com/rna (my identity URI) and
http://seairth.com/rna/12345 (my inbox URI) to http://rnaserv.net/bob (Bob's
identity URI). I get back a response containing my original entries plus
http://rnaserv.net/bob (Bob's idenitity URI) and
http://rnaserv.net/bob/44953324 (Bob's inbox URI).  At this point, I
can assert the relationship between his identity URI and his inbox URI are
valid.

Phase 2: Bob POSTs the same document that was returned in the last response
to http://seairth.com/rna (my identity URI).  If it is valid, I return the
document back again.  At this point, because I have confirmed the document,
Bob can be sure of my own relationships between my URI and the capability
URIs (both mine and his). If it is not valid (e.g. because I recognize that
I did not issue http://seairth.com/rna/12345 (my inbox URI)), I return an
error (which HTTP response code?), which tells Bob that something was wrong
and that he should probably invalidate his own inbox URI (as well as not use
the one I, or someone impersonating me, sent him in the first place).


Solution To Pattern #2:

Phase 1: I POST http://seairth.com/rna (my identity URI) to
http://rnaserv.net/bob (Bob's identity URI). I get back a response
containing my original entry plus http://rnaserv.net/bob (Bob's identity
URI) and http://rnaserv.net/bob/44953324 (Bob's inbox URI).  At this point,
I can assert the relationship between his identity URI and his inbox URI are
valid.

Phase 2: Bob POSTs the same document that was returned in the last response
to http://seairth.com/rna (my identity URI).  If it is valid, I return the
document back again.  At this point, because I have confirmed the document,
Bob can be sure of the relationship between my identity URI and the his
inbox URI. If it is not valid (which would be unlikely, unless someone else
tried to impersonate Bob), I return an error (which HTTP response code?),
which tells Bob that something was wrong and that he should probably
invalidate his own inbox URI.


Solution To Pattern #3:

Phase 1: I POST http://seairth.com/rna (my identity URI) and
http://seairth.com/rna/12345 (my inbox URI) to http://rnaserv.net/bob. I get
back a response containing my original entries plus http://rnaserv.net/bob
(Bob's identity URI).

Phase 2: Bob POSTs the same document that was returned in the last response
to http://seairth.com/rna (my identity URI).  If it is valid, I return the
document back again.  At this point, because I have confirmed the document,
Bob can be sure of the relationships between my identity URI and my inbox
URI. If it is not valid (e.g. because I recognize that I did not issue
http://seairth.com/rna/12345 (my inbox URI)), I return an error (which HTTP
response code?), which tells Bob that something was wrong and that he should
not use the inbox URI I, or someone impersonating me, sent him in the first
place.

---

I think the use of "capability URI" was a bit ambiguous (though I would hope
that Tyler could read it easily enough <g>).  Does this work better?

---
Seairth Jacobs
seairth@...

From: "Mike Dierken" <mdierken@...>
>
> From: "Seairth Jacobs" <seairth@...>
>
> > I've been continuing to give this some thought.  At this point, I'm
still
> > not sure whether notifications should have URIs.  For instance, in HTTP,
> we
> > think nothing of pulling a representation of a resource.  But what about
> > pushing a representation of a resource?
> Isn't that what PUT does?

That's not what I mean.  Suppose the notification has an associated URI like
http://seairth.com/rna/234.  Now, what I want to do is push a representation
of that resource to a recipient server.  I am not creating a new resource on
the recipient server, just pushing a representation of my own resource.  I
think that POST would be used here.  However, the recipient doesn't really
have a way to *know* that the POSTed representation belongs to the resource
at http://seairth.com/rna/234 unless the recipient turns around and GETs the
representation from that URI.  So then we are back to the question of "why
push a representation?".

---
Seairth Jacobs
seairth@...

> You will notice that Phase 2 is pretty much the same in all three cases.
> The only difference is who passes a capability URI in Phase 1.  So... what
> do you all think?  Does this work?  Is it RESTful?  Is there a better way?

Hmm, I may need to re-read this a dozen times first to make sure I
understand who is posting what to whom. I find it difficult to map the
examples that you gave to the idea of sending someone an email, which was
much easier to see in the earlier versions.

Michael Day

--
YesLogic Prince prints XML!
http://yeslogic.com/prince

> However, if the attacker has the ability to eavesdrop, then for
> either mechanism, he can just wait until the server sends the
> resource representation, and read it directly off the wire.
> There's no need to get either the secret URL or the user/password.

Hah, that's very true! :)

> I suggest you develop several use-cases for RNA and then decide
> what types of attackers you wish to defend against. Otherwise, you
> are just wasting your time.

Good advice, that sounds like a more robust way to evaluate the security
of the specification.

Michael Day

--
YesLogic Prince prints XML!
http://yeslogic.com/prince

----- Original Message -----
From: "Seairth Jacobs" <seairth@...>

> I've been continuing to give this some thought.  At this point, I'm still
> not sure whether notifications should have URIs.  For instance, in HTTP,
we
> think nothing of pulling a representation of a resource.  But what about
> pushing a representation of a resource?
Isn't that what PUT does?

For those of you who read my last post ("More on capabilities and RNA"), I
am looking to trade "capability URIs" up front instead of relying on the
query mechanism (which I hope to get rid of altogether).  In order to do
this, there are basically three possible patterns I want to support:

1) Sender and reciever trade capability URIs.  This is good for general
two-way notifications such as e-mail, forums, etc.
2) Sender gets capability URI from receiver.  This is good for situations
where a sender wants to push notifications,but not get them.  For instance,
this could be used to do things like submit entries to a search engine,
aggregator, etc.
3) Receiver sends capability URI to sender.  This is good for situations
where a recipient wants to "subscribe" to read-only notifications.  For
instance, this could be used to receive stock quotes, news headlines, etc.


Ideally, I would like to come up with a pattern for #1 which encompasses #2
and #3.

Also, these capability URIs must be guarnateed to match the general RNA
URIs.  In other words, if I (http://seairth.com/rna) were to receive a
capability URI (http://rnaserv.net/bob/2342344) from Bob
(http://rnaserv.net/bob), Bob must be sure that I was the one who received
the capability URI and I must be sure that Bob is the one who gave me the
capability URI (ignoring eavesdroppers).  This should be true both ways.

Here are my thoughts so far.  Please feel free to tear them apart!

If I POST to http://rnaserv.net/bob returned a capability URI, I would know
that relationship between his URI and his capability URI was valid.
However, Bob would not know the same between my URI and his capability URI.

If I POST to http://rnaserv.net/bob, which causes Bob to turn around and
POST the capability URI to http://seairth.com/rna, then Bob would know the
relationship to be valid, but I would not.

In other words, the only way I can validate the relationship is if the
capability URI returned in response to the first POST, while Bob must rely
on the valid connection of the second POST to validate the relationship.

So, the only way I have thought of so far is a two-phase exchange:


Solution To Pattern #1:

Phase 1: I POST http://seairth.com/rna and http://seairth.com/rna/12345 (my
capability URI) to http://rnaserv.net/bob. I get back a response containing
my original entries plus http://rnaserv.net/bob and
http://rnaserv.net/bob/44953324 (Bob's capability URI).  At this point, I
can assert the relationship between his URI and his capability URI are
valid.

Phase 2: Bob POSTs the same document that was returned in the last response
to http://seairth.com/rna.  If it is valid, I return the document back
again.  At this point, because I have confirmed the document, Bob can be
sure of my own relationships between my URI and the capability URIs (both
mine and his). If it is not valid (because I recognize that I did not issue
http://seairth.com/rna/12345, for instance), I return an error (which HTTP
response code?), which tells Bob that something was wrong and that he should
probably invalidate his own capability URI (as well as not use the one I, or
someone impersonating me, sent him in the first place).


Solution To Pattern #2:

Phase 1: I POST http://seairth.com/rna to http://rnaserv.net/bob. I get back
a response containing my original entry plus http://rnaserv.net/bob and
http://rnaserv.net/bob/44953324 (Bob's capability URI).  At this point, I
can assert the relationship between his URI and his capability URI are
valid.

Phase 2: Bob POSTs the same document that was returned in the last response
to http://seairth.com/rna.  If it is valid, I return the document back
again.  At this point, because I have confirmed the document, Bob can be
sure of my own relationships between my URI and the his capability URIs. If
it is not valid (which would be unlikely), I return an error (which HTTP
response code?), which tells Bob that something was wrong and that he should
probably invalidate his own capability URI.


Solution To Pattern #3:

Phase 1: I POST http://seairth.com/rna and http://seairth.com/rna/12345 (my
capability URI) to http://rnaserv.net/bob. I get back a response containing
my original entries plus http://rnaserv.net/bob.

Phase 2: Bob POSTs the same document that was returned in the last response
to http://seairth.com/rna.  If it is valid, I return the document back
again.  At this point, because I have confirmed the document, Bob can be
sure of my own relationships between my URI and my capability URIs. If it is
not valid (because I recognize that I did not issue
http://seairth.com/rna/12345, for instance), I return an error (which HTTP
response code?), which tells Bob that something was wrong and that he should
not use the capability URI I, or someone impersonating me, sent him in the
first place.


You will notice that Phase 2 is pretty much the same in all three cases.
The only difference is who passes a capability URI in Phase 1.  So... what
do you all think?  Does this work?  Is it RESTful?  Is there a better way?

---
Seairth Jacobs
seairth@...

As I have been working through the rewrite of the draft, a thought occured
to me.  Would there be any advantage in doing the following:

Instead of sending notifications directly to http://seairth.com/rna, suppose
that a sender must first POST a request to get back a URI which
notifications can be sent to (which would be used from that point on).  If I
understand correctly, this would be a "capability URI" (Tyler, please
correct me if I'm wrong).  A recipient could issue a capability URI to each
potential sender (or deny the request).  Or, as may be likely with a mailing
list, only a single capability URI would be issued.  More advanced
algorithms may do something in between (e.g., if within the same domain, use
a single, global capability, otherwise use individual capabilities).  In the
event that the recipient wanted to invalidate the URI, he would just stop
responding to it (410?).  All senders who got the response would need to
acquire a new capability URI (if the recipient wanted to give it out).  This
would allow, for instance, a recipient to give out a URI in an online form.
If the company processing the form shared the URI with other people or
companies, you would be able to rescind the URI.

In general, I really like this idea.  I have also been trying to think if
this could be used as a replacement for the <query> mechanism.  For
instance, if the above POST contained the sender's generic URI, the
recipient could POST the capability URI to that address instead of return in
the sender's POST response.  This would indicate that that the sender's
generic URI was valid.  From that point on, the <from> element in any
notification that was received through the capability URI would have to
contain the sender's generic URI.  If it didn't, you knew that the
capability URI was shared.  If it did, but the resource was obviously *not*
from the sender, then you would know that the capability URI was
compromised.  Either way, you revoke the URI and the hole is closed.

This potentially gets even better.  Take a mailing list, for example.  In
order to subscribe, all you would have to do is POST the above request to
the mailing list's generic URI.  This would return a capability URI to the
list.  At the same time, the list would do the same to your own generic URI.
Now, the bi-directional link is established.  Later, if you wanted to
unsubscribe, all you would do is revoke the capability URI.  The first time
the listserv got back a 410 response, it would know you no longer wanted to
receive notifications and would remove you from its list (as well as
possibly revoke its own capability URI to you).

So...  good?  bad?  let me hear it!

---
Seairth Jacobs
seairth@...

From: "Tyler Close" <tyler@...>
> As we've discussed, and you've agreed, using a capability URL is
> the only way to prevent the Confused Deputy attack. How do you
> reconcile this with thinking that a capability URL is "a Bad
> Idea"? The agreed facts indicate the exact opposite.

A server implementation could use http://user:pwd@seairth.com/rna/r/1234,
http://seairth.com/rna/r/1234/334956923, http://seairth.com/rna/334956923,
etc.  From the perspective of RNA, it doesn't matter.  The URI is opaque.
However, from the implementation perspective, each has its strengths and
weaknesses.  Personally, I don't think the "capability URL" is a Bad Idea.
Within my implementation that I am slowly working on, this will be the
approach I happen to be taking.  However, I prefer the "user:pwd@" format
for the various reasons that I have already stated.  If someone wants to use
nonces instead, that's up to them.  Again, it doesn't matter to RNA.

---
Seairth Jacobs
seairth@...

On Monday 05 May 2003 09:52, Seairth Jacobs wrote:
> From: "Tyler Close" <tyler@...>
>
> > Does this mean that you are dropping authorization methods 2 and
> > 5, from Michael Day's list of 5 authorization methods?
>
> Nope.  See below.

I don't understand. In the previous email, you agreed that these
methods are vulnerable to a Confused Deputy attack and said that
RNA passes the "user/pwd" in the notification.

> > Does this mean that you are rescinding your opinion that:
> > "Generating URLs containing authentication tokens seems like a Bad
> > Idea"?
>
> Nope.  See below.

A "user/pwd" is an authorization token. Are you saying that the
primary authorization mechanism used in RNA is "a Bad Idea"?

As we've discussed, and you've agreed, using a capability URL is
the only way to prevent the Confused Deputy attack. How do you
reconcile this with thinking that a capability URL is "a Bad
Idea"? The agreed facts indicate the exact opposite.

Tyler

From: "Tyler Close" <tyler@...>
>
> Does this mean that you are dropping authorization methods 2 and
> 5, from Michael Day's list of 5 authorization methods?

Nope.  See below.

> Does this mean that you are rescinding your opinion that:
> "Generating URLs containing authentication tokens seems like a Bad
> Idea"?

Nope.  See below.

> Taking this step raises a question about another part of the RNA
> design. If the resource identifier and the authority to access the
> resource are always transferred as a single unit, why does RNA
> contain a mechanism to authenticate the source of a notification?
> What attack does this authentication mechanism defeat?

Simple impersonation.  For instance, you may have an address like
http://rnaserv.com/close/tyler.  I may have a higher trust in notifications
that come from that address.  However, since a notification is pushed, it
could come from *anywhere*.  So, it would be possible for someone other than
yourself to send me a notfication that indicates you as the sender.  Or,
someone could just as easily give a totally ficticious address.

Now, I have to admit that I am not very fond of the query mechanism.  There
are certainly more elegant ways of solving the problem, but I felt it was
important to provide a simple version within the specification.  This means
that, even if a more elegant solution is layered on top (e.g. PKI
signatures), if a particular client cannot take advantage of the solution,
it can still "fall back" to the query mechanism.

As always, if there is a way that capabilities can make queries unnecessary,
I am all ears.

> > Also, the reason I suggest using user/pwd instead of a random,
unguessable
> > token in the URI is because I think the user/pwd is more in line with
the
> > REST philosophy.
>
> Please explain.
>
> > This ensures that a single uri (sans the "user:pwd@
> > part") identifies the same representation of the resource regardless of
> > which authentication credentials are provided, which is important for
> > things like caching proxies, etc...
>
> But given the decisions you've made above, the same authentication
> credentials are always provided. If you start mixing and matching
> authentication credentials and URLs, then you once again open
> yourself up to a Confused Deputy attack.
>
> A cache is perfectly happy with a URL that contains a secret in
> the path.

But it is not the place of RNA to dictate how a particular server is
implemented.  As a result, a server may choose to use a single URI for all
recipients of a given resource.  In this case, it would make little
difference between using a "user/pwd" or a nonce in the URI.  However, a
server may want to issue a separate capability URI to each recipient of the
same resource.  In this case, I would recommend using multiple "user/pwd"
pairs instead of multiple nonces in the URI, again for the purpose of
efficient caching, etc.


> > As I understand it, the sender has a resource he want's to make
available
> > to a recipient.  The sender assigns a capability (URI + user/pwd,  in
this
> > case) and gives it to the recipient.  Now, maybe I am not understanding
the
> > subtleties of a "capability URI".  If I have got it wrong, can you given
an
> > example (possibly in context of RNA) that would make the difference more
> > clear?
>
> Assuming you mean a unique "user/pwd" for each resource, and that
> the combined URI is passed using a secure communications channel,
> then the URI is a "capability URI".

Suppose you were to send a capability URI to two recipients.  How would you
revoke the capability for just one recipient?  It seems to me you would have
to revoke the first capability, then re-issue a new capability to the single
recipient.  Otherwise, the only other approach I see would be to generate
two capability URIs to start with...

>
> I think the only subtlety you are missing is that there is no
> advantage to using a "user/pwd" instead of a nonce in the URI
> path. On the other hand there are disadvantages to using HTTP
> Auth. You are doubling your network round trips, for no useful
> purpose.

Yes, I agree that there is additional overhead using HTTP Auth.  If your
server were implemented such that a single capability were generated
regardless of the number of people accessing the resource (recipients), then
using the nonce may be a more efficient way to go...

---
Seairth Jacobs
seairth@...

On Saturday 03 May 2003 13:58, Seairth Jacobs wrote:
> From: "Tyler Close" <tyler@...>
> > The problem is that the receiver is making the request using the
> > URL specified by the attacker and the receiver's own credentials.
> >
> > This type of attack is not possible in a capability-based design
> > because the resource identifier and the authority to access the
> > resource are bound together. If the notification delivered a
> > capability URL, then the receiver would access the resource using
> > the credentials provided by the notification producer, and not the
> > receiver's credentials. In this case, the resource request would
> > be associated with the notification producer, not the recipient.
>
> But this *is* the scenario right now, if I understand you correctly.  The
> recipient receives a notification that looks like:
>
> <notification>
>     <from uri="http://seairth.com/rna">
>     <resource uri="http://user:pwd@seairth.com/rna/msg/1234" />
> </notification>
>
> The recipient is using only credentials given to him via the notification.

Yes, using this type of construction, you avoid a Confused Deputy
attack on the notification receiver.

Does this mean that you are dropping authorization methods 2 and
5, from Michael Day's list of 5 authorization methods?

Does this mean that you are rescinding your opinion that:
"Generating URLs containing authentication tokens seems like a Bad
Idea"?

If the answer to both of these questions is yes, then this is a
big step in the right direction.

Taking this step raises a question about another part of the RNA
design. If the resource identifier and the authority to access the
resource are always transferred as a single unit, why does RNA
contain a mechanism to authenticate the source of a notification?
What attack does this authentication mechanism defeat?

> Also, the reason I suggest using user/pwd instead of a random, unguessable
> token in the URI is because I think the user/pwd is more in line with the
> REST philosophy.

Please explain.

> This ensures that a single uri (sans the "user:pwd@
> part") identifies the same representation of the resource regardless of
> which authentication credentials are provided, which is important for
> things like caching proxies, etc...

But given the decisions you've made above, the same authentication
credentials are always provided. If you start mixing and matching
authentication credentials and URLs, then you once again open
yourself up to a Confused Deputy attack.

A cache is perfectly happy with a URL that contains a secret in
the path.

> As I understand it, the sender has a resource he want's to make available
> to a recipient.  The sender assigns a capability (URI + user/pwd,  in this
> case) and gives it to the recipient.  Now, maybe I am not understanding the
> subtleties of a "capability URI".  If I have got it wrong, can you given an
> example (possibly in context of RNA) that would make the difference more
> clear?

Assuming you mean a unique "user/pwd" for each resource, and that
the combined URI is passed using a secure communications channel,
then the URI is a "capability URI".

I think the only subtlety you are missing is that there is no
advantage to using a "user/pwd" instead of a nonce in the URI
path. On the other hand there are disadvantages to using HTTP
Auth. You are doubling your network round trips, for no useful
purpose.

> I think there may be some miscommunication here (on my part).

I also made some mistakes in the email using examples from the RNA
spec. I confused the purpose of the authentication mechanism
described there. I think I get it now, but now that I understand
it, I no longer see what value it provides. See the question
above.

> This conversation has certainly helped.  Thank you.  I do have some
> questions, however.  I believe that the above approach effectively uses
> capabilities, but I still do not understand how any additional protection
> can be afforded to the sender than there already is by using capabilities.

Given the assumptions that I listed above, your approach does use
capabilities and there is no additional protection that can be
afforded. Thus my question about the purpose of your
authentication mechanism.

It's great that you've moved so quickly to using capability-based
security.

Tyler

From: "Chuck Hinson" <cmhinson@...>
>
> - After looking at your reply example, it occurs to me that it might be
> desirable to require that the notification (which contain metadata for
> the message) and the message have parallel existances.  (Warning -
> possbily half-baked idea ahead) So, when you send a message, both the
> message and the notification are created on the sender's server as
> separater (but related) resources.  Authenticity is acheived by doing a
> GET on the notification resource.  When you reply, you reference the
> notification resource on the sender's server rather than the message
> itself.  Either that, or messages have to have a link to their
> metadata.  Actually, this could be like SMTP messages, except that you
> would make the headers and the body two different resources, with the
> headers being used as the notification. (Of course a lot of the SMTP
> headers wouldnt be useful in RNA)


I've been continuing to give this some thought.  At this point, I'm still
not sure whether notifications should have URIs.  For instance, in HTTP, we
think nothing of pulling a representation of a resource.  But what about
pushing a representation of a resource?

Suppose we were to have a notification that looked like (warning!  new look.
online doc not yet updated to match.):

<rna xmlns="http://purl.oclc.org/rna/draft">
     <notification uri="http://seairth.com/rna/n/234962">
         <from uri="http://seairth.com/rna" />
         <resource uri="http://www.seairth.com/web/rna" />
         <subject>RNA Specification</subject>
     </notification>
</rna>

Now, presumably, if the recipient were to do a GET on
http://seairth.com/rna/n/234962, a representation of the notification would
be returned, looking like the notification just sent.  The query process
would be able to ask about the notification instead of the resource, but all
this would prove is that the sender did send a notification which can by
found at the given URI.  It does prove that the notification was unchanged
(e.g. is the resource in the received notification the same as the resource
in the notification at the URI.  The notification could be returned in
response to the query (as it is designed now), but then we would now have
three different ways that a representation of the notification could be
returned.  Not to mention that it seems unRESTful to return a representation
of another resource (the notification) as a response to a POST or GET on the
senders URI.


Also, what would be the advantages for the notification to have a URI?
There may be some, but the few I thought I had come up with turned out to
contain faulty arguements.

I don't want to rule this idea out yet, but I am somewhat unsure of where to
go with it...

---
Seairth Jacobs
seairth@...

From: "Tyler Close" <tyler@...>
>
> On Friday 02 May 2003 14:36, Seairth Jacobs wrote:
> > Why is the recipient forced to access the resource?  The decision to
access
> > the resource is 100% under the control of the recipient (and recipient's
> > application).  No external source can force the resource to be
retrieved.
> > It is certainly possible that a recipient could carelessly believe a
> > legitimate notification, but I'm not aware of *any* security model that
can
> > stop a recipient from being careless.
>
> The problem is that the ACL model makes it very difficult to not
> be careless with your authority.
>
> Assume the recipient has the authority to read a large number of
> resources on some server. Further assume that the recipient does
> not want his own credentials to be associated with a request to
> some of those resources. If the recipient makes a request using a
> URL taken from a notification, then the producer of the
> notification is deciding which resource the receiver will access.
> The receiver has delegated control over his ability to make
> requests to the notification producer.

Okay.  I agree with this.

> The problem is that the receiver is making the request using the
> URL specified by the attacker and the receiver's own credentials.
>
> This type of attack is not possible in a capability-based design
> because the resource identifier and the authority to access the
> resource are bound together. If the notification delivered a
> capability URL, then the receiver would access the resource using
> the credentials provided by the notification producer, and not the
> receiver's credentials. In this case, the resource request would
> be associated with the notification producer, not the recipient.

But this *is* the scenario right now, if I understand you correctly.  The
recipient receives a notification that looks like:

<notification>
     <from uri="http://seairth.com/rna">
     <resource uri="http://user:pwd@seairth.com/rna/msg/1234" />
</notification>

The recipient is using only credentials given to him via the notification.
Any person in the world could, given knowledge of the value of the "uri"
attribute, access the resource.  At the same time, it would be possible for
a sender to use the same user/pwd for several recipients.  However, this is
up to the discretion of the creator of the resource (who may or may not be
the same as the sender of the notification).  From the client's perspective,
all of this is opaque.

Also, the reason I suggest using user/pwd instead of a random, unguessable
token in the URI is because I think the user/pwd is more in line with the
REST philosophy.  This ensures that a single uri (sans the "user:pwd@ part")
identifies the same representation of the resource regardless of which
authentication credentials are provided, which is important for things like
caching proxies, etc...

As I understand it, the sender has a resource he want's to make available to
a recipient.  The sender assigns a capability (URI + user/pwd,  in this
case) and gives it to the recipient.  Now, maybe I am not understanding the
subtleties of a "capability URI".  If I have got it wrong, can you given an
example (possibly in context of RNA) that would make the difference more
clear?

> The attack is not so much targeted at RNA, as it is at how RNA is
> used. In the previous emails, you were indicating that the RNA
> client would provide a stored username/password in a request for a
> received notification URL. Doing this opens you up to a Confused
> Deputy attack.

I think there may be some miscommunication here (on my part).  Those
statements were made with the assumption that the examples at
http://www.seairth.com/web/rna were read.  Any stored user/password pairs
were provided by the sender of the notification, not by the recipient.  I
had meant "stored" only in terms of the user/password that was kept by the
recipient from the notification.

>
> I think I've explained things more clearly this time. Do you
> understand now?

This conversation has certainly helped.  Thank you.  I do have some
questions, however.  I believe that the above approach effectively uses
capabilities, but I still do not understand how any additional protection
can be afforded to the sender than there already is by using capabilities.
When I went and looked up information on the Confused Deputy attack, I did
not see how it applied to this situation.  If you still see problems what
capabilities was applied wrong, please let me know.

---
Seairth Jacobs
seairth@...