Next in thread →
Next in month →
Re: [xdi] Minutes: XDI TC Telecon Friday 2013-07-19
Dan, great points. Below is an updated copy of the minutes reflecting your points. Thanks, =Drummond ************ 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. We then talked about next steps. Dan suggested 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 Dan started to review last week. Dan 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). To continue progress, our next steps are: Identify the precise set of use cases that need to be diagrammed. In particular, we need to be specific how is each use case triggered. For example, in the flows above, how does Alice discover the XDI resource that she will request from Bob? 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. 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. On Sun, Jul 21, 2013 at 1:17 PM, Dan Blum <> wrote: 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 <> 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: 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? 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. 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.
Next in thread →
Next in month →