Hi everybody, this is pretty long and if course reserves aren't important to you, you might just want to skip it.
One of the points I made in my Jangle presentation was the necessity to create some Jangle connectors *outside* the ILS/OPAC to demonstrate how the entities might be used completely differently in a different context.
I chose to try this in Reserves Direct (http://www.reservesdirect.org/) for a couple of reasons: 1. A project I'm involved with at Talis is fairly similar to it and could benefit from design decisions made for modeling course reserves 2. Reserves Direct is fairly mature and open source (although with its own OSS license, seemingly); I can run it locally and hack on it 3. The internal data model is fairly consistent with other products in the domain 4. Course reserves are probably one of the more important "library integration" services for external applications, like courseware. 5. I helped write the original version and participated in the design of the current version, so am pretty familiar with it
This, like all of the other connectors to date, is written primarily as a proof-of-concept to get a grip on the data model. It could probably work as a production service (with slight modification), but that's more of an exercise of a Reserves Direct user, I think.
Anyway, on to how Jangle applies to this.
First off, a rough sketch of how "reserves" are modeled in Reserves Direct:
There are two critical relationships in Reserves Direct: 1. How reserved items relate to courses 2. How courses relate to people
Internally, RD has a lot of granularity around the notion of 'courses' (since there are crosslistings and aliases and sections of the same 'course', etc.), which Jangle is sort of hand-waving around at the moment, but for simplicity's sake, RD breaks course reserves into: 1. Users - this includes instructors, teaching assistants, students, staff, etc. 2. Course names, crossreferences and aliases 3. Specific instantiations of a course (i.e. HISTORY 100 - Introduction to Western Civilization section 4 taught by Joe Schmoe - Spring Semester 2009) 4. Roles of users to a specific course - user X is an instructor, users A, B and C are students, etc. 5. Departments that courses fall under 6. Libraries that serve departments 7. Items, section headings and notes about items 8. Association of items and headings to specific course instances
With slight variations, I think the same could generally be said of Syrup, ERes, ARes and Talis's Aspire (which is, technically speaking, a 'reading list manager', but I think the argument could be made that it shares pretty much all of the above attributes).
Jangle, for the uninitiated, divides any given service into four distinct resource 'types' or 'entities': 1. Actors 2. Collections 3. Items 4. Resources
Where 'Resources' are the primary 'asset' of the given service, 'Items' are specific manifestations of things, 'Actors' are users or account holders of a given system and 'Collections' are aggregations of other entities. It then provides an API to these resources using the Atom Publishing Protocol. Jangle also has a 'connector API' that translates the business logic of a particular system as JSON objects for a Jangle core to serialize as Atom documents.
A straw proposal I'm making for how to map those to reserves is this:
What's significant about this data model is that the actual 'things' themselves (a scanned book chapter, link to Proquest, copy held at reserves desk, etc.) are not represented except via a link relationship with the Item entity. My personal opinion is that this is a more versatile approach since the 'holdings' of a reserves system are generally widely distributed among some sort of PDF archive, web links and circulating copies of things. There is no reason why the link relationship couldn't be to another Jangled system.
Anyway, I realize that's a lot to look at. I CC'ed in the people that are working on these reserves system to get their take on the translation of the data model to Jangle. I'd be interested in any feedback, and, "uh... what?" is a perfectly reasonable response.
An important relationship when it comes to reserves is actor -> resource ->
items. Should jangle have a way to consider making that request, or is it
assumed that it would be 2 requests: actor -> resources and then resources
-> items?
On Mon, Mar 16, 2009 at 2:01 PM, Ross Singer <rossfsin...@gmail.com> wrote:
> Hi everybody, this is pretty long and if course reserves aren't
> important to you, you might just want to skip it.
> One of the points I made in my Jangle presentation was the necessity
> to create some Jangle connectors *outside* the ILS/OPAC to demonstrate
> how the entities might be used completely differently in a different
> context.
> I chose to try this in Reserves Direct
> (http://www.reservesdirect.org/) for a couple of reasons:
> 1. A project I'm involved with at Talis is fairly similar to it and
> could benefit from design decisions made for modeling course reserves
> 2. Reserves Direct is fairly mature and open source (although with its
> own OSS license, seemingly); I can run it locally and hack on it
> 3. The internal data model is fairly consistent with other products in
> the domain
> 4. Course reserves are probably one of the more important "library
> integration" services for external applications, like courseware.
> 5. I helped write the original version and participated in the design
> of the current version, so am pretty familiar with it
> This, like all of the other connectors to date, is written primarily
> as a proof-of-concept to get a grip on the data model. It could
> probably work as a production service (with slight modification), but
> that's more of an exercise of a Reserves Direct user, I think.
> Anyway, on to how Jangle applies to this.
> First off, a rough sketch of how "reserves" are modeled in Reserves Direct:
> There are two critical relationships in Reserves Direct:
> 1. How reserved items relate to courses
> 2. How courses relate to people
> Internally, RD has a lot of granularity around the notion of 'courses'
> (since there are crosslistings and aliases and sections of the same
> 'course', etc.), which Jangle is sort of hand-waving around at the
> moment, but for simplicity's sake, RD breaks course reserves into:
> 1. Users - this includes instructors, teaching assistants, students, staff,
> etc.
> 2. Course names, crossreferences and aliases
> 3. Specific instantiations of a course (i.e. HISTORY 100 -
> Introduction to Western Civilization section 4 taught by Joe Schmoe -
> Spring Semester 2009)
> 4. Roles of users to a specific course - user X is an instructor,
> users A, B and C are students, etc.
> 5. Departments that courses fall under
> 6. Libraries that serve departments
> 7. Items, section headings and notes about items
> 8. Association of items and headings to specific course instances
> With slight variations, I think the same could generally be said of
> Syrup, ERes, ARes and Talis's Aspire (which is, technically speaking,
> a 'reading list manager', but I think the argument could be made that
> it shares pretty much all of the above attributes).
> Jangle, for the uninitiated, divides any given service into four
> distinct resource 'types' or 'entities':
> 1. Actors
> 2. Collections
> 3. Items
> 4. Resources
> Where 'Resources' are the primary 'asset' of the given service,
> 'Items' are specific manifestations of things, 'Actors' are users or
> account holders of a given system and 'Collections' are aggregations
> of other entities. It then provides an API to these resources using
> the Atom Publishing Protocol. Jangle also has a 'connector API' that
> translates the business logic of a particular system as JSON objects
> for a Jangle core to serialize as Atom documents.
> A straw proposal I'm making for how to map those to reserves is this:
> What's significant about this data model is that the actual 'things'
> themselves (a scanned book chapter, link to Proquest, copy held at
> reserves desk, etc.) are not represented except via a link
> relationship with the Item entity. My personal opinion is that this
> is a more versatile approach since the 'holdings' of a reserves system
> are generally widely distributed among some sort of PDF archive, web
> links and circulating copies of things. There is no reason why the
> link relationship couldn't be to another Jangled system.
> Anyway, I realize that's a lot to look at. I CC'ed in the people that
> are working on these reserves system to get their take on the
> translation of the data model to Jangle. I'd be interested in any
> feedback, and, "uh... what?" is a perfectly reasonable response.
Yeah, well, this is, obv., a good question, and I don't think it's
strictly limited to the reserves domain (although I think this is the
first compelling example of it).
The only current barrier to this sort of request is that the
frameworks don't have the capacity to respond to it.
What, exactly, is the intended response from this? All the reserves
associated with any course associated with an actor? i.e.
/actors/1234/resources/items ?
Or is there the expectation that a particular course ID would be
included in the mix?
/actors/1234/resources/4321/items ?
The former is going to require a lot of rethinking of how routes work
in Jangle. This throws some variance in the URL patterns that will
make processing them somewhat more complicated (since at any resource
you could be requesting an ID, IDs, category or, with this,
relationship).
The latter is certainly doable. In the case of ResDirect (and
Aspire), it obviously gives the connector the option of adding a
"hidden" category, as well.
I'm not sure I have any objections to this on the surface, and, of
course, this sort of request is completely at the discretion of the
connector developer.
The questions I have at this point, I guess, are:
* What jangle:relationship URIs are returned from /actors/1234/resources/4321?
or, for that matter:
* What relationship URIs are returned from /actors/1234/resources/ ?
Do we need URIs to both the possibly filtered or adulterated
actors-related resources (and items) and the original?
* /actors/1234/resources/4321, /actors/1234/resources/4322, etc.
and
* /resources/4321, /resources/4322 # This being the way Jangle currently works
This isn't a valid relation in Atom, so we'd have to mint a rel URI
like we do for alternate formats, something like
http://jangle.org/vocab/rel#canonical
What do people think? Like I mentioned earlier, this has value
outside of the course reserves context.
On Tue, Mar 17, 2009 at 8:35 AM, Emily Lynema <emilylyn...@gmail.com> wrote:
> An important relationship when it comes to reserves is actor -> resource ->
> items. Should jangle have a way to consider making that request, or is it
> assumed that it would be 2 requests: actor -> resources and then resources
> -> items?
> -emily
> On Mon, Mar 16, 2009 at 2:01 PM, Ross Singer <rossfsin...@gmail.com> wrote:
>> Hi everybody, this is pretty long and if course reserves aren't
>> important to you, you might just want to skip it.
>> One of the points I made in my Jangle presentation was the necessity
>> to create some Jangle connectors *outside* the ILS/OPAC to demonstrate
>> how the entities might be used completely differently in a different
>> context.
>> I chose to try this in Reserves Direct
>> (http://www.reservesdirect.org/) for a couple of reasons:
>> 1. A project I'm involved with at Talis is fairly similar to it and
>> could benefit from design decisions made for modeling course reserves
>> 2. Reserves Direct is fairly mature and open source (although with its
>> own OSS license, seemingly); I can run it locally and hack on it
>> 3. The internal data model is fairly consistent with other products in
>> the domain
>> 4. Course reserves are probably one of the more important "library
>> integration" services for external applications, like courseware.
>> 5. I helped write the original version and participated in the design
>> of the current version, so am pretty familiar with it
>> This, like all of the other connectors to date, is written primarily
>> as a proof-of-concept to get a grip on the data model. It could
>> probably work as a production service (with slight modification), but
>> that's more of an exercise of a Reserves Direct user, I think.
>> Anyway, on to how Jangle applies to this.
>> First off, a rough sketch of how "reserves" are modeled in Reserves
>> Direct:
>> There are two critical relationships in Reserves Direct:
>> 1. How reserved items relate to courses
>> 2. How courses relate to people
>> Internally, RD has a lot of granularity around the notion of 'courses'
>> (since there are crosslistings and aliases and sections of the same
>> 'course', etc.), which Jangle is sort of hand-waving around at the
>> moment, but for simplicity's sake, RD breaks course reserves into:
>> 1. Users - this includes instructors, teaching assistants, students,
>> staff, etc.
>> 2. Course names, crossreferences and aliases
>> 3. Specific instantiations of a course (i.e. HISTORY 100 -
>> Introduction to Western Civilization section 4 taught by Joe Schmoe -
>> Spring Semester 2009)
>> 4. Roles of users to a specific course - user X is an instructor,
>> users A, B and C are students, etc.
>> 5. Departments that courses fall under
>> 6. Libraries that serve departments
>> 7. Items, section headings and notes about items
>> 8. Association of items and headings to specific course instances
>> With slight variations, I think the same could generally be said of
>> Syrup, ERes, ARes and Talis's Aspire (which is, technically speaking,
>> a 'reading list manager', but I think the argument could be made that
>> it shares pretty much all of the above attributes).
>> Jangle, for the uninitiated, divides any given service into four
>> distinct resource 'types' or 'entities':
>> 1. Actors
>> 2. Collections
>> 3. Items
>> 4. Resources
>> Where 'Resources' are the primary 'asset' of the given service,
>> 'Items' are specific manifestations of things, 'Actors' are users or
>> account holders of a given system and 'Collections' are aggregations
>> of other entities. It then provides an API to these resources using
>> the Atom Publishing Protocol. Jangle also has a 'connector API' that
>> translates the business logic of a particular system as JSON objects
>> for a Jangle core to serialize as Atom documents.
>> A straw proposal I'm making for how to map those to reserves is this:
>> What's significant about this data model is that the actual 'things'
>> themselves (a scanned book chapter, link to Proquest, copy held at
>> reserves desk, etc.) are not represented except via a link
>> relationship with the Item entity. My personal opinion is that this
>> is a more versatile approach since the 'holdings' of a reserves system
>> are generally widely distributed among some sort of PDF archive, web
>> links and circulating copies of things. There is no reason why the
>> link relationship couldn't be to another Jangled system.
>> Anyway, I realize that's a lot to look at. I CC'ed in the people that
>> are working on these reserves system to get their take on the
>> translation of the data model to Jangle. I'd be interested in any
>> feedback, and,
>What, exactly, is the intended response from this? All the reserves >associated with any course associated with an actor? i.e. >/actors/1234/resources/items ?
>Or is there the expectation that a particular course ID would be >included in the mix?
>/actors/1234/resources/4321/items ?
I like the idea that the URLs keep burrowing deeper into the options, so that "/actors/1234/resources/4321/items" is listed as one of the collections for "/actors/1234/resources/items". Bloglines, and maybe every feed consumer for all I know, has this nice feature that you give it a URL and it lists all of the possibilities.
In Ontario, folks can get really touchy about displaying IDs that map to a student. Would it be out of line to use a URI like "actors/student/resources/4321/items" and have an authentication layer sort out identity?
Castor, an xml framework that long ago fell out of the limelight, used to have this wonderful slogan that it's purpose was to be "the shortest path from here to there". It's very cool how Jangle seems to follow this philosophy so well.
On Tue, Mar 17, 2009 at 3:51 PM, <artrh...@uwindsor.ca> wrote: > In Ontario, folks can get really touchy about displaying IDs that map to a > student. Would it be out of line to use a URI like > "actors/student/resources/4321/items" and have an authentication layer sort > out identity?
This seems inordinately complicated to me. Besides, at some point you're going to need systems that are able to authoritatively correlate user accounts between systems, won't you? How would, say, courseware be able to present to an instructor, the current roll of his or her class?
No matter what, I think there needs to be a stub of an ID there.
There are a couple ways, I guess, this could work. One possibility would be to contrive a 'dummy' identifier, something like: /actors/____/ (or any string that you're not afraid of namespace collisions) that sets off the authentication mechanism.
Another possibility would be a mechanism to set up a salt between the client and server and hash the IDs. I'm not sure how complicated this is, though, or if it just moves the same problem to a different location.
To get a better understanding here, the danger is exposing that actor X is enrolled in course Y?
So it seems like /actors/1234/resources is "ok", but /actors/1234/resources/4321/items is "not ok", is that right?
The problems with the authentication method that I can see are: 1) how does a 'authorized' third party (such as an internal harvester for another application or something) manage this? 2) how do you request multiple actors: /actors/1234,1235/resources/4321?
These are good ideas, though, keep 'em coming.
> Castor, an xml framework that long ago fell out of the limelight, used to
Well, thanks Art, I think we now have Jangle's new slogan:
"Jangle, like an xml framework that long ago fell out of the limelight"
> To get a better understanding here, the danger is exposing that actor > X is enrolled in course Y?
Yes, but I am no expert on our new privacy laws and I might be wrong about this. I used to have a few newspaper feeds that required userid/passwords, though I think they all went open or went out of business.
> "Jangle, like an xml framework that long ago fell out of the limelight"
See, and people wonder why newspapers are in trouble with marketing minds like mine behind their operation :-)
On Tue, Mar 17, 2009 at 4:50 PM, <artrh...@uwindsor.ca> wrote:
>> To get a better understanding here, the danger is exposing that actor >> X is enrolled in course Y?
> Yes, but I am no expert on our new privacy laws and I might be wrong about > this.
I'm not an expert either, but I would agree that publishing 'X is enrolled in Y' would be a concern, at least at our institution.
From the little I've read about Jangle, it's just Atom, and so it seems to me that protection can happen at the HTTP layer: Simply forbid access (403) to anyone who shouldn't have access to the 'X in Y' information. Upgrade sensitive URLs to TLS to add some extra tinfoil (if that doesn't cause an interop nightmare). So, /actors/NNN(.*) and /resources/NNN/actors could be on a need-to-resolve basis: you can know the URL but not the contents.
Isn't all of this stuff need-to-know anyway? For reserves, wouldn't an institution be more interested in interop between reserves and, say, an LMS or a portal? Would you really share these data with everyone? (I'm new here, be patient if that's short-sighted. :-)
Re: salting and hashing userids -- I get the idea, but don't see the specific application. The URLs themselves don't appear to contain userids, rather you have numeric identifiers for users. Presumably there's a search facility that could resolve userids to /actors/NNN/ URLs? And that facility could be protected at the HTTP level? If my identifier in the Jangle interface is my /actors/NNN/ URL, I can't imagine the privacy police being too upset (as long as the wrong people couldn't resolve it and get at my personal details).
But maybe I'm reading too much into the example. Were you planning on /actors/<userid>/ and using numbers as examples of userids?
(Either way, salting/hashing smells like security at the wrong level, IMHO. Use the transport protocol, Luke.)
Oh, one other thing. In Syrup, we've allowed for nested headings of arbitrary depth. I'm not sure we're going to keep them, but if we do, it would be nice to be able to model this properly in a Jangle connector.
>> "Jangle, like an xml framework that long ago fell out of the limelight"
I sort of like it, actually. Makes me wonder what it fell *into*. :-)
> "Jangle, like an xml framework that long ago > fell out of the limelight"
+1
--Dave
==================
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu ________________________________________
From: jangle-discuss@googlegroups.com [jangle-discuss@googlegroups.com] On Behalf Of Graham Fawcett [graham.fawc...@gmail.com]
Sent: Tuesday, March 17, 2009 4:40 PM
To: jangle-discuss@googlegroups.com
Cc: chris.cla...@talis.com; Graham Fawcett; Jason White; Maurice_Y...@ncsu.edu; Nadeem.Sha...@talis.com; Art Rhyno; rossfsin...@gmail.com
Subject: [jangle-discuss] Re: Rough proof-of-concept Jangle Connector for Reserves Direct
Hi folks,
On Tue, Mar 17, 2009 at 4:50 PM, <artrh...@uwindsor.ca> wrote:
>> To get a better understanding here, the danger is exposing that actor
>> X is enrolled in course Y?
> Yes, but I am no expert on our new privacy laws and I might be wrong about
> this.
I'm not an expert either, but I would agree that publishing 'X is
enrolled in Y' would be a concern, at least at our institution.
From the little I've read about Jangle, it's just Atom, and so it
seems to me that protection can happen at the HTTP layer: Simply
forbid access (403) to anyone who shouldn't have access to the 'X in
Y' information. Upgrade sensitive URLs to TLS to add some extra
tinfoil (if that doesn't cause an interop nightmare). So,
/actors/NNN(.*) and /resources/NNN/actors could be on a
need-to-resolve basis: you can know the URL but not the contents.
Isn't all of this stuff need-to-know anyway? For reserves, wouldn't an
institution be more interested in interop between reserves and, say,
an LMS or a portal? Would you really share these data with everyone?
(I'm new here, be patient if that's short-sighted. :-)
Re: salting and hashing userids -- I get the idea, but don't see the
specific application. The URLs themselves don't appear to contain
userids, rather you have numeric identifiers for users. Presumably
there's a search facility that could resolve userids to /actors/NNN/
URLs? And that facility could be protected at the HTTP level? If my
identifier in the Jangle interface is my /actors/NNN/ URL, I can't
imagine the privacy police being too upset (as long as the wrong
people couldn't resolve it and get at my personal details).
But maybe I'm reading too much into the example. Were you planning on
/actors/<userid>/ and using numbers as examples of userids?
(Either way, salting/hashing smells like security at the wrong level,
IMHO. Use the transport protocol, Luke.)
Oh, one other thing. In Syrup, we've allowed for nested headings of
arbitrary depth. I'm not sure we're going to keep them, but if we do,
it would be nice to be able to model this properly in a Jangle
connector.
>> "Jangle, like an xml framework that long ago fell out of the limelight"
I sort of like it, actually. Makes me wonder what it fell *into*. :-)
Graham, you're right on target when it comes to Jangle's use of URIs. "/actors/1234" is an arbitrary identifier, local to, say, Syrup. So the primary key that identifies gfawc...@windsor.ca in Syrup's users and user_profiles tables would be the identifier here. There would probably be a search mechanism to be able to find this identifier, but, yes, it makes sense to protect this with auth/authz.
This is how the connector for Talis Alto (our ILS) works. If you request /actors/ or any subdirectory of /actors/ you'll get a 401. The options are to pass an administrative account to get 'anything' or your personal credentials where you can only get you. If you request /actors/ there will only be one result. If you request an ID that isn't you, you'll get a 403.
I suppose the danger here is an unauthorized caching and reuse of legitimate client requests.
I am in the course management system, I request my reserves (and other things) which starts the process by resolving who I am (which grabs my personal information in a vcard or a foaf).
Since, I, the user, is not interacting with Jangle directly, there is a level of trust that the agent isn't doing something untoward with this data. At this point we *do* have a URI that associates a person to their identity.
My preference is to still leave this *out of the spec* (e.g. leave it as an exercise of the implementer). I think hashing out a way to reconcile this issue and including this solution in the reference implementations (as well as documenting it explicitly) is imperative, however.
Basically, I don't want to see Jangle fall out of favor because some early implementations exposed delicate data insecurely and it was easier to abandon it than solve the problem.
I want Jangle to fall out of favor because it closely resembles some Java XML parser that nobody uses anymore.
> On Tue, Mar 17, 2009 at 4:50 PM, <artrh...@uwindsor.ca> wrote:
>>> To get a better understanding here, the danger is exposing that actor >>> X is enrolled in course Y?
>> Yes, but I am no expert on our new privacy laws and I might be wrong about >> this.
> I'm not an expert either, but I would agree that publishing 'X is > enrolled in Y' would be a concern, at least at our institution.
> From the little I've read about Jangle, it's just Atom, and so it > seems to me that protection can happen at the HTTP layer: Simply > forbid access (403) to anyone who shouldn't have access to the 'X in > Y' information. Upgrade sensitive URLs to TLS to add some extra > tinfoil (if that doesn't cause an interop nightmare). So, > /actors/NNN(.*) and /resources/NNN/actors could be on a > need-to-resolve basis: you can know the URL but not the contents.
> Isn't all of this stuff need-to-know anyway? For reserves, wouldn't an > institution be more interested in interop between reserves and, say, > an LMS or a portal? Would you really share these data with everyone? > (I'm new here, be patient if that's short-sighted. :-)
> Re: salting and hashing userids -- I get the idea, but don't see the > specific application. The URLs themselves don't appear to contain > userids, rather you have numeric identifiers for users. Presumably > there's a search facility that could resolve userids to /actors/NNN/ > URLs? And that facility could be protected at the HTTP level? If my > identifier in the Jangle interface is my /actors/NNN/ URL, I can't > imagine the privacy police being too upset (as long as the wrong > people couldn't resolve it and get at my personal details).
> But maybe I'm reading too much into the example. Were you planning on > /actors/<userid>/ and using numbers as examples of userids?
> (Either way, salting/hashing smells like security at the wrong level, > IMHO. Use the transport protocol, Luke.)
> Oh, one other thing. In Syrup, we've allowed for nested headings of > arbitrary depth. I'm not sure we're going to keep them, but if we do, > it would be nice to be able to model this properly in a Jangle > connector.
>>> "Jangle, like an xml framework that long ago fell out of the limelight"
> I sort of like it, actually. Makes me wonder what it fell *into*. :-)
Hi Ross. A good conversation here, if a slowly-developing one. :-)
On Tue, Mar 17, 2009 at 11:11 PM, Ross Singer <rossfsin...@gmail.com> wrote: > Graham, you're right on target when it comes to Jangle's use of URIs. > "/actors/1234" is an arbitrary identifier, local to, say, Syrup. So > the primary key that identifies gfawc...@windsor.ca in Syrup's users > and user_profiles tables would be the identifier here. There would > probably be a search mechanism to be able to find this identifier, > but, yes, it makes sense to protect this with auth/authz.
> This is how the connector for Talis Alto (our ILS) works. If you > request /actors/ or any subdirectory of /actors/ you'll get a 401. > The options are to pass an administrative account to get 'anything' or > your personal credentials where you can only get you. If you request > /actors/ there will only be one result. If you request an ID that > isn't you, you'll get a 403.
Great -- no wheel-reinvention here. :-)
> I suppose the danger here is an unauthorized caching and reuse of > legitimate client requests. > I am in the course management system, I request my reserves (and other > things) which starts the process by resolving who I am (which grabs my > personal information in a vcard or a foaf).
Side note: vCard or FOAF? Is there a reason not to pick one? I'm just curious why you'd spec out the transfer protocol, but not the payload. Separation of concerns is all good, but if I was writing a Jangle stack I'd hope for clear answers from top to bottom, if you know what I mean.
In our case (Syrup), we really don't have much user information to share anyway -- in some cases, it might be just (userid, given, surname, email) or even just (userid) in the pathological case!
> Since, I, the user, is not interacting with Jangle directly, there is > a level of trust that the agent isn't doing something untoward with > this data. At this point we *do* have a URI that associates a person > to their identity.
That's fair, I think. That's a level of trust that the LMS would uphold with several other data-sources (its own database, notably, which is a hodgepodge of other people's sensitive stuff). I don't think Jangle would need to be held to a higher standard.
> My preference is to still leave this *out of the spec* (e.g. leave > it as an exercise of the implementer). I think hashing out a way to > reconcile this issue and including this solution in the reference > implementations (as well as documenting it explicitly) is > imperative, however.
In the Reserves context, are you thinking of exporting "content" from Reserves (e.g. PDFs and other documents) through APP? Or just publishing URLs pointing to those documents in the Reserves system? I'm thinking you mean the former, and that's why the security concerns are important, right?. (In contrast, a list-of-links doesn't seem worth protecting, really.)
Is there any notion in Jangle of a "lease" or a "guest pass"? E.g., here's a URL for my course-items, it has "full-read" access, and expires in thirteen weeks? The read-permissions are confined to the single course, and don't allow a user to 'escalate' access in other sites? The point is that part of the authorization-decision could be made by the Reserves user, inside the reserves system. A "lease" doesn't map directly onto any of the APP components, though it could be concieved as a sort-of course-like thing.
> Basically, I don't want to see Jangle fall out of favor because some > early implementations exposed delicate data insecurely and it was > easier to abandon it than solve the problem. I want Jangle to fall > out of favor because it closely resembles some Java XML parser that > nobody uses anymore.
|
