OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xdi] Minutes: XDI TC Telecon Friday 2013-07-19


Great minutes Drummond, and thanks so much Peter and Markus for the excellent sequence diagrams. I found the exercise quite productive.

Drummond, can you add to the minutes that, for the use cases presented, we should discuss whether any additional security exchanges need to take place or else note why they're not required? We started to get to this in a discussion about whether the UMA / OAuth / XDI messages needed to signed or encrypted, something which OpenID Connect now supports by reference to the JOSE specs which I'd started to review last week. I noted that we would required TLS anyway, something that OpenID requires but UMA does not. Peter noted that TLS protection is broken on any flow that redirects through a browser. So in those scenarios, tokens or other data that are being passed between entities need to be signed. 

Further, we didn't discuss in the UMA scenarios whether OpenID Connect Authentication was required (for Bob's AS to get an ID token or UserInfo to propoerly categorize Alice). We also need to decide how in the both the XDI case and the UMA /OAuth case we know from the flow that keys used to sign messages are valid, or if not we can check their status not revoked (hopefully without getting into a full PKI situation).

Dan


On Fri, Jul 19, 2013 at 9:31 PM, Drummond Reed <drummond.reed@xdi.org> wrote:

XDI TC Minutes


Following are the minutes of the unofficial telecon of the XDI TC at:


Date:  Friday, 19 July 2013 USA
Time:  09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)


ATTENDING

Les Chasen

Joseph Boyle

Markus Sabadello

Peter Davis

Phil Windley

Drummond Reed


AGENDA

NEWS & UPDATES

CLOUD IDENTITY SUMMIT REPORT

Drummond, Les, Peter, Dan, and Markus shared that they had an excellent set of sessions with Eve Maler and other UMA experts to discuss XDI security flows.



PRESENTATIONS/DISCUSSIONS

XDI SECURITY PATTERNS

We continued our review of mechanisms for XDI message authentication and authorization and how they align with OAuth and PKI.


  https://wiki.oasis-open.org/xdi/XdiMessagePatterns

  https://lists.oasis-open.org/archives/xdi/201305/msg00048.html


First, Peter reviewed the following diagram (including source text from WebSequenceDiagrams.com) of what the security flows would look like in the basic “Alice & Bob” scenario following the UMA (User Managed Access) drafft specification.







title Basic Alice to Bob use case for initial introduction to Bob's CSP


participant "Alice"

participant "AliceAS"

participant "AliceCSP"

participant "Bob"

participant "BobCSP"

participant "BobAS"

participant "Discovery"


Bob->BobCSP: register service

BobCSP->BobAS: resource registration

BobAS->BobCSP: OK

BobCSP->Bob: OK


Bob->BobAS: Allow Alice to resource

note right of BobAS: May be a generic policy\n(RBAC, etc...)

end note


BobAS->Bob: OK


Alice->Discovery: Where is Bob's CSP

Discovery->Alice: Bob's CS Location


Alice->+AliceCSP: Link contract request to Bob

AliceCSP->+BobCSP: Link contract request to Bob


BobCSP->AliceCSP: RPT Required

AliceCSP->Alice: RPT Required (authentication)

Alice->AliceCSP: authenticate


note right of BobAS

Allow explicit and implicit AS\nregistrations, so AAT message may not\nbe required

end note


AliceCSP->BobAS: AAT request

BobAS->AliceCSP: AAT Response


AliceCSP->BobAS: RPT request (with AAT)

note right of BobAS

this is where the actual\ncontract is generated

end note


BobAS->AliceCSP: RPT


AliceCSP->BobCSP: Resource request with RPT

BobCSP->BobAS: token validation

BobAS->BobCSP: response


BobCSP-->-AliceCSP: Resource

AliceCSP-->-Alice: Resource

*******


We noted in the discussion that the number of messages and tokens needed in UMA may be significantly consolidated by assuming XDI endpoints that serve in both the AS (Authorization Server) and RS (Resource Server, which is Peter’s diagram is CSP) roles.


Peter had to leave the call at 10AM PT. Continuing that discussion, Markus created another WebSequenceDiagram that showed a similar scenario using only XDI servers.



# Use this at http://www.websequencediagrams.com/


title Alice to Bob Flow in XDI


participant Alice

participant Bob

participant "Alice's XDI Server"

participant "Bob's XDI Server"

participant "XDI Discovery Service"


Bob->"Bob's XDI Server": Set up link contract

"Bob's XDI Server"->Bob: OK

alt Link contract address sent via E-Mail

 Bob->Alice: E-Mail with link contract address

else Link contract address dynamically discovered

 Alice->"Alice's XDI Server": Discover XDI link contract address

 "Alice's XDI Server"->"Bob's XDI Server": Discover XDI link contract address

 "Bob's XDI Server"->"Alice's XDI Server": XDI link contract address

 "Alice's XDI Server"->Alice: XDI link contract address

end

Alice->"Alice's XDI Server": Resource Request using XDI link contract address

"Alice's XDI Server"->"XDI Discovery Service": Discover Bob's XDI Server

"XDI Discovery Service"->"Alice's XDI Server": Discovery Result

"Alice's XDI Server"->"Bob's XDI Server": Request Resource

note right of "Bob's XDI Server"

Validate signature on Alice's

XDI message and verify

XDI link contract

end note

"Bob's XDI Server"->"Alice's XDI Server": Resource

"Alice's XDI Server"->Alice: Resource


********

In this scenario, peer-to-peer PKI is used by Bob’s XDI Server to validate Alice’s signature on the incoming resource request.


Everyone agreed this was a very useful exercise. To continue progress, our next steps are:

  1. Identify the precise set of use cases that need to be diagrammed. In particular, how is each use case triggered, i.e., how does Alice discover the XDI resource that she will request from Bob?

  2. We also need to identify the precise client configuration for each use case, i.e., the security considerations for plain browser, unhosted app, and native app may all vary.

  3. Across this matrix, prepare the diagrams the reflect the use of different authentication/authorization protocols (e.g., OAuth, OpenID Connect, UMA, PEERKI).



DECISION POINT QUEUE REVIEW

The decision queue stack is shown on the following three auto-generated Category pages:


  https://wiki.oasis-open.org/xdi/CategoryLastCall

  https://wiki.oasis-open.org/xdi/CategoryCurrent

  https://wiki.oasis-open.org/xdi/CategoryHighPriority


See also this list of proposals that need to be developed:


  https://wiki.oasis-open.org/xdi/XdiPendingIssues


NEXT CALL

Drummond will be on vacation next week, so he will not be able to attend the call, but unless Markus posts otherwise, assume there will still be a call at the regular time.






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]