1 / 9

Schema Updates and S/MIME Handling Improvements

This update includes changes to the schema to support language tagging and updated S/MIME handling. It also addresses the issue of credential transfer for resource subscriptions.

jmarissa
Download Presentation

Schema Updates and S/MIME Handling Improvements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Resource Lists Adam Roach adam@estacado.net

  2. Schema Updates • Moved “name” attribute on <list> and <resource> changed to element to support language tagging • Formally restricted “state” attribute in schema to reect the three valid values outlined in the text

  3. Example: Old Format <list xmlns="urn:ietf:params:xml:ns:rlmi" uri="sip:adam-friends@lists.example.com" version="7" fullState="true" name="Buddy List"> <resource uri="sip:bob@example.com" name="Bob Smith"> <instance id="juwigmtboe" state="active" cid="12345.aaa@example.com"/> </resource> <resource uri="sip:dave@example.com" name="Dave Jones"> <instance id="hqzsuxtfyq" state="active" cid="12345.aab@example.com"/> </resource> </list>

  4. Example: New Format <list xmlns="urn:ietf:params:xml:ns:rlmi" uri="sip:adam-friends@lists.example.com" version="7" fullState="true"> <name language="en">Buddy List</name> <name language="fr">Liste d'amis</name> <resource uri="sip:bob@example.com> <name>Bob Smith</name> <instance id="juwigmtboe" state="active" cid="12345.aaa@example.com"/> </resource> <resource uri="sip:dave@example.com"> <name>Dave Jones</name> <instance id="hqzsuxtfyq" state="active" cid="12345.aab@example.com"/> </resource> </list>

  5. S/MIME Handling • Changed to reference most current S/MIME handling • Removed references to multipart/encrypted; replaced with application/pcks7-mime (per RFC 3261)

  6. Open Issue: Credential Transfer • In order to subscribe on a user’s behalf to a resource, the RLS must have access to that user’s credentials. • Currently, the draft species no mandatory-to-implement mechanism. (HTML forms over HTTPS are mentioned as one possible means). • The IESG is requesting that the document specify or cite a mandatory-to-implement mechanism.

  7. Credential Transfer: Ideas • Make HTML forms mandatory • Add new SIP method or header eld for credential upload (realm/username/password) • Disallow back-end subscriptions altogether (i.e. list server would pass back list in response, and the client would be required to subscribe to the state for any resources not managed by that server) • Try to leverage ongoing work in draft-ietf-sip-identity and/or draft-jennings-sipping certs (e.g. co-locate an authentication service with the RLS, and have it insert an Identity header; this requires the RLS to be in the same domain as the user.)

  8. Credential Transfer: Proposal 1 • Don’t transfer credentials; RLS always subscribes using its own credentials • Any back-end subscriptions reveal whatever information the resource is willing to reveal to RLS (generally, anything non-sensitive) • Add ag to RLMI documents to indicate for which resources the RLS is not authoritative • Punt for future work the denition of a mechanism or mechanisms to allow the RLS to cryptographically assert that the user has authorized it to subscribe on their behalf.

  9. Credential Transfer: Proposal 2 • Put the event list stuff back on the back burner. (It’s been over four years since we started this work in IMPP; it’s used to it). • Mount an effort to solve the “I’m making this request on behalf of user A and here’s my token to prove it” problem. • Resolve the issue as in proposal 1, except without the RLMI ag indicating authoritativeness.

More Related