[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Post Meeting thought... RE: [id-cloud] 19 March 2012 Meeting Minutes of the Oasis IDCloud TC
Folks on the call Just thinking again about this part of the conversation.... << Dominique Nguyen (Bank of America): Gap identified: The need for a higher security profile to access the resource. Dominique Nguyen (Bank of America): Recommend to enhance both OAuth and OpenID to have higher security profile to access the resource Matt Rutkowski (IBM): OpenID Connect Dominique Nguyen (Bank of America): openID Connec needs to be added - description can be based on OAuth but extended>> And David Turner also made references to 'work going on'. Whether that was an explicit or implicit reference to the IETF JOSE project I don't know, but I think it is relevant here. As I understand it, this 'work going on' is how OpenIDConnect intends to secure its JSON Web Tokens. So we are at this point again - do we include profiles or specs that have not yet completed standardisation? While it is not 100% clear where the JOSE work will fall (that discussion is going on this week), it would seem to me to be helpful for readers of this doc, if we included JOSE as 'an applicable standard - to be confirmed' or something. Now if I have connected these dots completely wrong, please say so and I'll put it down to a combination of an early morning and NSTIC/IDTrust jetlag:-) Cheers Colin -----Original Message----- From: id-cloud@lists.oasis-open.org [mailto:id-cloud@lists.oasis-open.org] On Behalf Of Anil Saldhana Sent: Tuesday, 20 March 2012 8:14 a.m. To: id-cloud Subject: [id-cloud] 19 March 2012 Meeting Minutes of the Oasis IDCloud TC ============= David Kern (IBM): Hmm... doesn't look like we've reached quorum yet. Roger Bass morphed into Roger Bass (Traxian) David Kern (IBM): Anil - have you started the call yet? anonymous morphed into Cathy Tilton (Daon) AnilSaldhana(RedHat): just did it AnilSaldhana(RedHat): David Kern: it takes like 90 secs to start the call. David Kern (IBM): wow... AnilSaldhana(RedHat): ========= AnilSaldhana(RedHat): Agenda 1) Roll Call, Agenda Review and Minute Taker Nomination. 2) Approval of the 5 March 2012 Meeting Minutes. http://lists.oasis-open.org/archives/id-cloud/201203/msg00028.html 3) [VOTE] Approve Editor's Draft (http://www.oasis-open.org/committees/download.php/45416/id-cloud-usecases-v1.0-wd02a.doc) as Committee Note Draft and send it to 15 day Public Review. 4) Gap Analysis Discussion. 5) Other Business. 6) Adjourn. AnilSaldhana(RedHat): ========================== AnilSaldhana(RedHat): Roll Call: 6 out of 10 voting members (60%): achieved Dominique Nguyen (Bank of America): Hi, i Dominique Nguyen (Bank of America): m in the chat room now Dominique Nguyen (Bank of America): 2nd item Approval of March 5 meeting meeting AnilSaldhana(RedHat): http://lists.oasis-open.org/archives/id-cloud/201203/msg00035.html AnilSaldhana(RedHat): Approval of 5th march 2012 meeting minutes AnilSaldhana(RedHat): Dominique: moves. Anil: seconds Dominique Nguyen (Bank of America): no ojection AnilSaldhana(RedHat): meeting minutes approved. Matt Rutkowski (IBM): http://www.oasis-open.org/apps/org/workgroup/id-cloud/download.php/45416/id-cloud-usecases-v1.0-wd02a.doc AnilSaldhana(RedHat): Approve Editor's Draft (http://www.oasis-open.org/committees/download.php/45416/id-cloud-usecases-v1.0-wd02a.doc) as Committee Note Draft and send it to 15 day Public Review. AnilSaldhana(RedHat): Matt: moves Dominique Nguyen (Bank of America): Matt moves to move the draft approved last week to be raised for final public review AnilSaldhana(RedHat): Tony: second Dominique Nguyen (Bank of America): no ojection AnilSaldhana(RedHat): motion passes. AnilSaldhana(RedHat): 4) IPR discussion AnilSaldhana(RedHat): *6 to mute your lines Dominique Nguyen (Bank of America): Tony: we do committee notes & we want vendor organizations to take our output and there is no standard bodies to take our output Dominique Nguyen (Bank of America): there is some discussions at the OASIS level to see what can happen Matt Rutkowski (IBM): there is no approved way in our OASIS IP process to allow Comm. Nots that have been approved for other SDOs to reference/use Matt Rutkowski (IBM): we may have to resolve this within our TC Dominique Nguyen (Bank of America): current OASIS IPR prohibits this - so this will be a big change Dominique Nguyen (Bank of America): Tony & Jamie discussed at great length last week Dominique Nguyen (Bank of America): Technical notes are work that we did & we want other TCs to be able to take our use cases & gaps and use them as their input Dominique Nguyen (Bank of America): No other committees can take our notes right now Dominique Nguyen (Bank of America): unless there is rule change Dominique Nguyen (Bank of America): Anil will create the TC request AnilSaldhana(RedHat): Matt: u able to type in the minutes? Dominique Nguyen (Bank of America): Gap Analysis discussion: AnilSaldhana(RedHat): Use Case 21 is all about Mobile Identity. Matt Rutkowski (IBM): http://www.oasis-open.org/committees/document.php?document_id=44915&wg_abbrev=id-cloud Dominique Nguyen (Bank of America): Use Case 21: Mobile Customers' Identity Authentication Using a Cloud Provider Short description: Feature the need to have a standard secure authentication in order to use Cloud service to authenticate mobile users Relevant applicable standards: - SAML - OAuth - XSPA - WS-Trust - PMRM OAuth v 1.0a Gap summary: This standard provides no security mechanism to protect the confidentiality and integrity of the information passed between User to Service Provider and Service Provider to Consumer. Thus it exposes the id exchange information to eavesdrop and information theft by Man-in-the-Middle and Man-in-the Browser attacks. The protocol relies on SSL/TLS to provide security for information exchanged in motion. However, if mutual authentication is not enforced in the SSL/TLS handshake connection, SSL/TLS is also subject to eavesdrop and information theft by Man-in-the-Middle and Man-in-the Browser attacks. . Terms used in OAuth and detailed gaps: * Service Provider: A web application that allows access via OAuth * User: Individual who has account with Service Provider * Consumer: A website or application that uses OAuth to access the Service Provider on behalf of the User * Consumer Key: A value used by the Consumer to identify itself to the Service Provider * Consumer Secret: A secret used b the Consumer to establish ownership of the Consumer Key * Request Token: A value used by the Consumer to obtain authorization from the User, and exchanged for an Access Token * Access Token: A value used by the Consumer to gain access to the Protected Resources on behalf of the User, instead of using the Users Service Provider credential * Token Secret: A secret used by the Consumer to establish ownership of a given Token Standard / ProtocolCredentials & Token ExchangePlaintext signatureConfidentiality of RequestsSpoofing by Counterfeit ServersPlaintext Storage of CredentialsSecrecy of the Consumer SecretScoping of Access RequestsCross-Site Request ForgeryAutomatic Processing of Repeat Authorization OAuth 1.0aNo mechanism to protect Tokens & secrets from eavesdroppers when transmitted from Service Provider to CustomerNo attempt to protect User credentials from eavesdroppers or man-in-he-middle attacks. This method is intended to be used in conjunction with a transport-layer security mechanism such as TLS or SSLOnly provides mechanism for verifying the integrity of requests, not confidentiality of the request, eavesdroppers will have full access to request contentNo attempt to verify the authenticity of the Service Provider. 3rd party can intercept the Consumers request and returning misleading or incorrect responsesConsumer Secret and Token Secret are stored in plaintext form for Service Provider to compute the signatures used in the non-plaintext methodsThis is a single factor secret and can be downloaded by attackerBy itself, OAuth does not provide any method for scoping the access rights granted to a Consumer would either has access to Protected Resources or it doesnt.CSRF web-based attacks on OAuth approvals allow an attacker to obtain authorization to OAuth Protected Resources without the consent of the UserAn attacker can use the stolen Consumer Key and Secret to redirect the User to the Service Provider with an authorization request. The Service Provider will then grant access to the Users data without the Users explicit approval Matt Rutkowski (IBM): Use Case 21: Mobile Customers' Identity Authentication Using a Cloud Provider Short description: Feature the need to have a standard secure authentication in order to use Cloud service to authenticate mobile users Relevant applicable standards: - SAML - OAuth - XSPA - WS-Trust - PMRM SAML v2.0 Information Card Token Profile Vers1on 1.0 - Gap summary: Dominique Nguyen (Bank of America): Gap identified: The need for a higher security profile to access the resource. Dominique Nguyen (Bank of America): Recommend to enhance both OAuth and OpenID to have higher security profile to access the resource Matt Rutkowski (IBM): OpenID Connect Dominique Nguyen (Bank of America): openID Connec needs to be added - description can be based on OAuth but extended Dominique Nguyen (Bank of America): 3rd gap to be considered Discovery of profiles - some level of discovery in openID Connect already started - we can look at it as a start Dominique Nguyen (Bank of America): Meeting adjourns - we will meet in 2 weeks Dominique Nguyen (Bank of America): Today's attendees: Dominique Nguyen (Bank of America): AnilSaldhana(RedHat) Anthony Nadalin Cathy Tilton (Daon) Colin Wallis (NZGovt) David Turner (Microsoft) Dominique Nguyen (Bank of America) Matt Rutkowski (IBM) David Kern (IBM) Roger Bass (Traxian) ============================================================= --------------------------------------------------------------------- To unsubscribe, e-mail: id-cloud-unsubscribe@lists.oasis-open.org For additional commands, e-mail: id-cloud-help@lists.oasis-open.org ==== CAUTION: This email message and any attachments contain information that may be confidential and may be LEGALLY PRIVILEGED. If you are not the intended recipient, any use, disclosure or copying of this message or attachments is strictly prohibited. If you have received this email message in error please notify us immediately and erase all copies of the message and attachments. Thank you. ====
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]