1 / 9

Solving the identity crisis draft-ietf-geopriv-common-policy-05

Solving the identity crisis draft-ietf-geopriv-common-policy-05. Henning Schulzrinne Aki Niemi Hannes Tschofennig Jonathan Rosenberg. Current solution. different identities authenticated unauthenticated asserted anonymous asserted mapped to authenticated identity

dblackwell
Download Presentation

Solving the identity crisis draft-ietf-geopriv-common-policy-05

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. Solving the identity crisisdraft-ietf-geopriv-common-policy-05 Henning Schulzrinne Aki Niemi Hannes Tschofennig Jonathan Rosenberg IETF63 - SIMPLE

  2. Current solution • different identities • authenticated • unauthenticated • asserted • anonymous • asserted mapped to authenticated identity • authorization based on anonymous identity not provided • too vague description in some cases <identity> <id entity="alice@example.com"/> <id entity="bob@example.com"/> </identity> <identity> <domain domain="example.com"/> <except domain=“foo.com"/> </identity> <any-identity> <domain domain=“bar.com”> <except-domain domain="example.com"/> <except-domaindomain="foo.com"/> </any-identity> IETF63 - SIMPLE

  3. Basic proposal • only authenticated identities • unauthenticated identities = omit <identity> one person identity :>= 1 person IETF63 - SIMPLE

  4. Asserted vs. authenticated • Do not make distinction in common-policy • Currently, have text on distinction, but hard to understand without reference to particular use case (SIP, etc.) • Suggestion: point to detailed discussion elsewhere IETF63 - SIMPLE

  5. Background: processing logic • All conditions are AND C1 AND C2 … • each condition can be OR within • If omitted, obviously not checked • for identity: any identity, authenticated or not • Only one of each kind of condition <conditions> <identity>…</identity> <sphere>…</sphere> <validity>…</validity> </conditions> AND IETF63 - SIMPLE

  6. Within each kind of condition • Allow OR conditions within <identity>, <validity>, <sphere>, …? • currently, defined for <identity> only • matches any of a list of identities • may want for others? • e.g, for sphere • reason: combinatorial explosion! IETF63 - SIMPLE

  7. Identity: Single individual/user/person/… • <one id=“alice@example.com”> • May contain tel: URIs • OR: <one id=“alice@example.com”/> <one id=“bob@example.com”/> OR IETF63 - SIMPLE

  8. >= 1 (groups) • can be combined with <one> -- OR • <many/> any authenticated • <many> <except domain=“example.com”/> [OR] <except domain=“foobar.com”/> </many>  all but enumerated domains • <many domain=“example.com”> <except id=“alice”/> [OR] <except id=“bob”/> </many>  all but enumerated individuals in domain IETF63 - SIMPLE

  9. tel URIs • tel URIs • other URIs that don’t have domains = “non-domain identifiers” • e.g., URN that uses passport numbers • Proposal 1: only allow non-domain identifiers in id=“tel:123” • doesn’t work: <many domain=“example.com”> <except id=“tel:123”/> </many> • Proposal 2: only allow domain identifiers in <many/> (non-domain in <one> only) IETF63 - SIMPLE

More Related