From hannes.tschofenig@gmx.net Fri Nov 1 10:32:36 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AD821E809A for ; Fri, 1 Nov 2013 10:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Md4iDbPHEk84 for ; Fri, 1 Nov 2013 10:32:32 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id C32D411E8174 for ; Fri, 1 Nov 2013 10:32:31 -0700 (PDT) Received: from masham-mac.home ([81.164.176.169]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LlDb4-1WBuFU3H1S-00b6aX for ; Fri, 01 Nov 2013 18:32:30 +0100 Message-ID: <5273E5AD.7010408@gmx.net> Date: Fri, 01 Nov 2013 18:32:29 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:jPp8VQr88WGdBZ2zLnU06TreJY3tnQVSS6heu+tPyZWNTq1zzPS TZ1kh3ai+jYofn+CQI+owv/Qeq7/usbO8ExxZaeyRNcLl/BPV3i2PSrOxqTwIIJrG0BGlgS y6vwhQr+qK0Qm3lObJj8pE/bw06CnKeD6u0h9Z7qc3W0hrFI/X/iRIfUwJXbGUbDF4yyOHE X4g4vIHSW7Y+QZ+ldkpqg== Subject: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 17:32:36 -0000 Hi John, Hi all, I read your document and here a few remarks. In the dynamic client registration conference calls the topic of the stateless client was raised since there was the argument in the air that the current OAuth 2.0 RFC requires clients to be stateless due to the nature of the client identifier. It seems that you have found a way to make the client stateless with regard to the client identifier (i.e., that the authorization server does not need to store information about the client) by dumping state information in the client identifier itself. In your case you use a JWT, which is clever. Since RFC 6749 explicitly says that the client identifier string size is left undefined and that the client should avoid making assumptions about the identifier size I don't see a problem with the proposed approach. Now, there is one issue that I am wondering about. The client identifier itself is not sufficient for authorizing the client (for confidential clients). Instead, there is typically the need to have a secret. Now, the secret is not conveyed in the JWT, at least not in the way you have define it. You could of course do that and there is a document that provides prior art, see http://www.ietf.org/rfc/rfc5077 The story essentially is that the structure (JWT in your case) includes the key but of course then you have to encrypt the entire blob. In the case of public clients wouldn't you want to mandate at least a digital signature or a keyed message digest for the JWT since otherwise there is the risk that the client changes some of the parameters to impersonate someone? A few other questions: * You write: "The issuer SHOULD sign the JWT with JWS in such a way that the signature can be verified by the authorization server. " I believe what you want to say is the following: The authorization creates the client identifier (using the JWT) and the client does not parse the received content since it treats it as opaque. However, the authorization server MUST be able to process and verify received client identifiers it previously created, which requires to apply cryptographic processing when a JWT is signed (using a JWS) and when a JWT is encrypted (using a JWE). (I ignore the issue that I believe the JWT needs to be signed [for public clients] and encrypted [for confidential clients].) * You should submit the document as draft-bradley-oauth; this makes it easier to find the document. * You write: " The issuer MAY encrypt the JWT with JWE. " I think you want to be stronger by saying that JWE MUST be used when the authorization server wants to apply confidentiality protection of the JWT. While the authorization server could use other techniques as well the purpose of the document is to describe one way to accomplish the goal and therefore it makes sense to be specific. I would even go as far as suggesting specific algorithms to use, as an example. * Although not stated directly I believe you allow the client identifier to be created by a party other than the authorization server. While this would theoretically make sense wouldn't it be useful to just assume that the issuer is the authorization server? Ciao Hannes From ve7jtb@ve7jtb.com Fri Nov 1 11:18:14 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E61F21E805D for ; Fri, 1 Nov 2013 11:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5h8xDCAaIFUD for ; Fri, 1 Nov 2013 11:18:09 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id 0B39611E8169 for ; Fri, 1 Nov 2013 11:18:07 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id e16so2634449qcx.34 for ; Fri, 01 Nov 2013 11:18:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=w9NG+yVAHlOJiZMTFsUllfXD+/bLj30sr58EVsEN2t8=; b=jNQHtgQ9v9tJlf0YzzEPKyIRjGemkISBpEymNIXEDex61Kpu1EVmrKEUSrTFJjIATV qrB9pffnVNyjYKEzqSXrQ3sepWWDSxddwd0YMzxE8MBBXvqBwAvuqFqofSjeu4mrS0vB LCj28qY+sO3867N6+hEgwM9/GHKGGYBrc7yRGVaaDQkh3P0Mfyb3HxMDJD9W+QIHvHI/ hdUIhKh57Y4vcLCc0SwaqgvrDREbs8OyD8JxyOR2QeCfYO4o8UzOGQC2+rRM336qlx/9 sqyl6PZzBILXOWDXnDPTuMDZR0+xV+smfTdGcRYwbssYLCK5E/KUganCDfZO0/BW/q5Y PVew== X-Gm-Message-State: ALoCoQnD1ywrQAK4tN28Z2jWgZA8ndoqskMF/+S12N+tmTrB3tt8QWZeWmVD/eHK4M5y0QyP1awF X-Received: by 10.49.35.15 with SMTP id d15mr5807268qej.16.1383329887082; Fri, 01 Nov 2013 11:18:07 -0700 (PDT) Received: from [192.168.1.216] (190-20-27-115.baf.movistar.cl. [190.20.27.115]) by mx.google.com with ESMTPSA id ge5sm19878156qeb.5.2013.11.01.11.18.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 11:18:04 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_2998B74F-5140-46A0-8F24-A5250CA8937C"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: John Bradley In-Reply-To: <5273E5AD.7010408@gmx.net> Date: Fri, 1 Nov 2013 15:18:00 -0300 Message-Id: <3F75FA0B-CAC3-439A-866B-CFE116FADA4E@ve7jtb.com> References: <5273E5AD.7010408@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1816) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 18:18:14 -0000 --Apple-Mail=_2998B74F-5140-46A0-8F24-A5250CA8937C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The client_id would continue to be opaque to the client as it is now. = The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and = provide integrity if it is using a symmetric key (probably the simplest = thing if we are talking about a single registration endpoint paired with = a single AS) In more complicated scenarios where perhaps a group of AS = share a single registration endpoint you probably want to use asymmetric = signature then asymmetric encryption + integrity. Those are = deployment decisions that need to be documented but can be transparent = to teh client. Sorry to my mind it is obvious that the JWT would be integrity = protected/signed for all clients including clients using asymmetric = authentication to the token endpoint, and and signed+encrypted+integrity = for clients using symmetric authentication. That can be made clearer. It might make sense to assume the issuer is just the AS but the AS can = do that without the benefit of a spec now, as there is no = interoperability issue. The spec defining the JWT structure and signing and encryption methods = has the most benefit when you don't have such a tight coupling between = registration and AS. That is likely why Justin and I didn't think a spec was necessary for = the simple case other than to show people this is possible with the = existing registration spec. I am OK with strengthening the wording on signing/integrity protecting = and encryption. eg if a symmetric key is included the JWT MUST be = encrypted. I don't necessarily want to make any algorithm a must as that limits = algorithm agility in the future. Thanks for giving it a read, see you Sunday I expect. John B. On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig = wrote: > Hi John, > Hi all, >=20 > I read your document and here a few remarks. >=20 > In the dynamic client registration conference calls the topic of the = stateless client was raised since there was the argument in the air that = the current OAuth 2.0 RFC requires clients to be stateless due to the = nature of the client identifier. >=20 > It seems that you have found a way to make the client stateless with = regard to the client identifier (i.e., that the authorization server = does not need to store information about the client) by dumping state = information in the client identifier itself. In your case you use a JWT, = which is clever. >=20 > Since RFC 6749 explicitly says that the client identifier string size = is left undefined and that the client should avoid making assumptions = about the identifier size I don't see a problem with the proposed = approach. >=20 > Now, there is one issue that I am wondering about. The client = identifier itself is not sufficient for authorizing the client (for = confidential clients). Instead, there is typically the need to have a = secret. Now, the secret is not conveyed in the JWT, at least not in the = way you have define it. You could of course do that and there is a = document that provides prior art, see http://www.ietf.org/rfc/rfc5077 > The story essentially is that the structure (JWT in your case) = includes the key but of course then you have to encrypt the entire blob. >=20 > In the case of public clients wouldn't you want to mandate at least a = digital signature or a keyed message digest for the JWT since otherwise = there is the risk that the client changes some of the parameters to = impersonate someone? >=20 > A few other questions: >=20 > * You write: > "The issuer SHOULD sign the JWT with JWS in such a way that the = signature can be verified by the authorization server. > " >=20 > I believe what you want to say is the following: The authorization = creates the client identifier (using the JWT) and the client does not = parse the received content since it treats it as opaque. However, the = authorization server MUST be able to process and verify received client = identifiers it previously created, which requires to apply cryptographic = processing when a JWT is signed (using a JWS) and when a JWT is = encrypted (using a JWE). >=20 > (I ignore the issue that I believe the JWT needs to be signed [for = public clients] and encrypted [for confidential clients].) >=20 > * You should submit the document as draft-bradley-oauth; this makes it = easier to find the document. >=20 > * You write: > " > The issuer MAY encrypt the JWT with JWE. > " >=20 > I think you want to be stronger by saying that JWE MUST be used when = the authorization server wants to apply confidentiality protection of = the JWT. While the authorization server could use other techniques as = well the purpose of the document is to describe one way to accomplish = the goal and therefore it makes sense to be specific. >=20 > I would even go as far as suggesting specific algorithms to use, as an = example. >=20 > * Although not stated directly I believe you allow the client = identifier to be created by a party other than the authorization server. = While this would theoretically make sense wouldn't it be useful to just = assume that the issuer is the authorization server? >=20 > Ciao > Hannes > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_2998B74F-5140-46A0-8F24-A5250CA8937C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMTAxMTgxODAwWjAjBgkqhkiG9w0BCQQxFgQUl4yMsS/Z KNZjC5N9Nm/Q64aEzEowgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAWw87IIpegYSvWXldQMk4ub66HkSV8WAuTd1MOoqu 6gH73xCt4JEhdRDbOWjHy9sq4SpYhFsFM2bNljqk2qOZW/NA3lEeTTtIUE/6e+R7kaQM6BuKhYCh qcjqowWFgCoY8G3d37f5jCrTU7CzpkeMdhJ5NyJvdA0x/i2trznzq2G7w/PpnUO+iWElotA5aRjb C/DuGvo1ctU/kO0fjlaqvNkwnZYESPKeIYYwe2JcsXNdfQH2bYFv8rC+3ItSQPiVLJ8bksB+4aNh 8njlAutjBdFYqXI+XeMshkparUZktvokBFeRc3ZCcADLHnoRm+QbJgtSBI+48W7oNeWlD9ogsQAA AAAAAA== --Apple-Mail=_2998B74F-5140-46A0-8F24-A5250CA8937C-- From hannes.tschofenig@gmx.net Fri Nov 1 11:49:15 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB0711E80DE for ; Fri, 1 Nov 2013 11:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSbbjCQfIkqy for ; Fri, 1 Nov 2013 11:49:11 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id CE96611E813D for ; Fri, 1 Nov 2013 11:49:09 -0700 (PDT) Received: from masham-mac.home ([81.164.176.169]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M4Gup-1VsslD4BBD-00roQ2 for ; Fri, 01 Nov 2013 19:49:09 +0100 Message-ID: <5273F7A2.70409@gmx.net> Date: Fri, 01 Nov 2013 19:49:06 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: John Bradley References: <5273E5AD.7010408@gmx.net> <3F75FA0B-CAC3-439A-866B-CFE116FADA4E@ve7jtb.com> In-Reply-To: <3F75FA0B-CAC3-439A-866B-CFE116FADA4E@ve7jtb.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:qFbuTTYWwNr3JssBMpBES4sbI/c3PQeXNd9PnOu9BTfwXILw67U HBe0i/umc1S6fp6X4mxpGnoy95g1p76Fp1rYvteIHmhaNiYXrNC+0qYG7d9zENVrnYw+bQ7 7gB8qJxBkoF3ENMpl63T8pDj4QPQj9/1r+GKsckzLYDRVKiUaLTvgCIvlsUj5pAH/q7Sf+k 9ZUpvNTWG1gF+kqsztAVw== Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 18:49:15 -0000 Hi John, thanks for the super-quick response. Am 01.11.13 19:18, schrieb John Bradley: > The client_id would continue to be opaque to the client as it is now. > The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and > provide integrity if it is using a symmetric key (probably the > simplest thing if we are talking about a single registration endpoint > paired with a single AS) In more complicated scenarios where perhaps > a group of AS share a single registration endpoint you probably want > to use asymmetric signature then asymmetric encryption + integrity. > Those are deployment decisions that need to be documented but can be > transparent to teh client. Maybe it would be good to state that in the document that this is a possible option without introducing further complications (other than the verification procedure is different). If the AS signs the JWT then it just needs to compare whether the issuer field matches what it had previously put in there. If someone else signs the JWT then it needs to check with some trust anchor store or something similar whether it trusts that specific issuer. > > Sorry to my mind it is obvious that the JWT would be integrity > protected/signed for all clients including clients using asymmetric > authentication to the token endpoint, and and > signed+encrypted+integrity for clients using symmetric > authentication. That can be made clearer. It would be good to say that because the effort is rather low and there are benefits in doing so. > > It might make sense to assume the issuer is just the AS but the AS > can do that without the benefit of a spec now, as there is no > interoperability issue. > > The spec defining the JWT structure and signing and encryption > methods has the most benefit when you don't have such a tight > coupling between registration and AS. > > That is likely why Justin and I didn't think a spec was necessary for > the simple case other than to show people this is possible with the > existing registration spec. I think there is value in providing that information for implementers even though it does not require new extensions or so. > > I am OK with strengthening the wording on signing/integrity > protecting and encryption. eg if a symmetric key is included the JWT > MUST be encrypted. Cool. > > I don't necessarily want to make any algorithm a must as that limits > algorithm agility in the future. OK. > > Thanks for giving it a read, see you Sunday I expect. Unfortunately not since I am unable to attend the upcoming IETF meeting. Derek will run the show. Ciao Hannes > > John B. > > > On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig > wrote: > >> Hi John, Hi all, >> >> I read your document and here a few remarks. >> >> In the dynamic client registration conference calls the topic of >> the stateless client was raised since there was the argument in the >> air that the current OAuth 2.0 RFC requires clients to be stateless >> due to the nature of the client identifier. >> >> It seems that you have found a way to make the client stateless >> with regard to the client identifier (i.e., that the authorization >> server does not need to store information about the client) by >> dumping state information in the client identifier itself. In your >> case you use a JWT, which is clever. >> >> Since RFC 6749 explicitly says that the client identifier string >> size is left undefined and that the client should avoid making >> assumptions about the identifier size I don't see a problem with >> the proposed approach. >> >> Now, there is one issue that I am wondering about. The client >> identifier itself is not sufficient for authorizing the client (for >> confidential clients). Instead, there is typically the need to have >> a secret. Now, the secret is not conveyed in the JWT, at least not >> in the way you have define it. You could of course do that and >> there is a document that provides prior art, see >> http://www.ietf.org/rfc/rfc5077 The story essentially is that the >> structure (JWT in your case) includes the key but of course then >> you have to encrypt the entire blob. >> >> In the case of public clients wouldn't you want to mandate at least >> a digital signature or a keyed message digest for the JWT since >> otherwise there is the risk that the client changes some of the >> parameters to impersonate someone? >> >> A few other questions: >> >> * You write: "The issuer SHOULD sign the JWT with JWS in such a way >> that the signature can be verified by the authorization server. " >> >> I believe what you want to say is the following: The authorization >> creates the client identifier (using the JWT) and the client does >> not parse the received content since it treats it as opaque. >> However, the authorization server MUST be able to process and >> verify received client identifiers it previously created, which >> requires to apply cryptographic processing when a JWT is signed >> (using a JWS) and when a JWT is encrypted (using a JWE). >> >> (I ignore the issue that I believe the JWT needs to be signed [for >> public clients] and encrypted [for confidential clients].) >> >> * You should submit the document as draft-bradley-oauth; this makes >> it easier to find the document. >> >> * You write: " The issuer MAY encrypt the JWT with JWE. " >> >> I think you want to be stronger by saying that JWE MUST be used >> when the authorization server wants to apply confidentiality >> protection of the JWT. While the authorization server could use >> other techniques as well the purpose of the document is to describe >> one way to accomplish the goal and therefore it makes sense to be >> specific. >> >> I would even go as far as suggesting specific algorithms to use, as >> an example. >> >> * Although not stated directly I believe you allow the client >> identifier to be created by a party other than the authorization >> server. While this would theoretically make sense wouldn't it be >> useful to just assume that the issuer is the authorization server? >> >> Ciao Hannes _______________________________________________ OAuth >> mailing list OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From hannes.tschofenig@gmx.net Fri Nov 1 12:02:07 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB00321E805D for ; Fri, 1 Nov 2013 12:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zi36eq+pRldl for ; Fri, 1 Nov 2013 12:02:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7358021E85DB for ; Fri, 1 Nov 2013 12:01:07 -0700 (PDT) Received: from masham-mac.home ([81.164.176.169]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MLO9y-1Vbljf3wg6-000fJD for ; Fri, 01 Nov 2013 20:01:06 +0100 Message-ID: <5273FA71.4000500@gmx.net> Date: Fri, 01 Nov 2013 20:01:05 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "oauth@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:y5b49YTHY8N5cjCogH3wpyye0asNarEwvvGl7Yo7Q4QZNZlrCAr K6pEZwE9bEvOgJ6t3rgNUIPbBE1132w4WJaOtUw6GA5mGt4JHH1VXN8872NBQX9FySHdYHF H+cvAlExYzRwoZfHsl2/bwKZPs3ICqxAktKg0XdUbjogusz4Fw/tp7V1VVFxHSvpoIepS/3 g6JaJ3tmwKVS3l3ztDwJg== Subject: [OAUTH-WG] draft-hunt-oauth-client-association-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 19:02:07 -0000 Hi Phil, Hi Tony, Hi all, I re-read the document and I believe the most important concept it introduces is the classification of different associations, namely into 'static', 'dynamic', and 'transient'. This is certainly something worthwhile to discuss during the meeting and to ensure that it is well understood, and that there are only these three classes (rather than two or four). The description in the introduction makes the differentiation between the three concepts mostly based on how the endpoints are configured in the application. With the static association the endpoint is hard-coded into the software during the development time. It cannot be changed. With the two other cases the endpoint can be changed. As such, the difference between the 'dynamic', and 'transient' association seems to be in the terms of how long the lifetime of the association. Now, what exactly is the lifetime of an association? Is the lifetime of the association understood as the lifetime of the configured endpoint identifier? Then, when I re-read the text in Section 1 again then I suddenly get the impression that the lifetime of the association actually does not matter but instead the difference is rather whether the client is public or confidential. Is that true? If it isn't true that this is the feature that makes the distinction between 'dynamic', and 'transient' then the notion of "public" vs. "confidential" client isn't too important for the rest of the document. Ciao Hannes From phil.hunt@oracle.com Fri Nov 1 12:02:23 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33EA021E8251 for ; Fri, 1 Nov 2013 12:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.257 X-Spam-Level: X-Spam-Status: No, score=-6.257 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Spmtss1bmHXJ for ; Fri, 1 Nov 2013 12:02:18 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5969E21E80E1 for ; Fri, 1 Nov 2013 12:02:01 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA1J1uxr000656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 1 Nov 2013 19:01:57 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA1J1tPT003309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 Nov 2013 19:01:56 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA1J1tYO004859 for ; Fri, 1 Nov 2013 19:01:55 GMT Received: from [192.168.1.12] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Nov 2013 12:01:55 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_4CF5D818-DDA2-40C0-BB2E-921B3BBA4B0F" Message-Id: Date: Fri, 1 Nov 2013 12:01:47 -0700 To: oauth list Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [OAUTH-WG] Client Association alternative to Dyn Reg and stateless oauth client X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 19:02:23 -0000 --Apple-Mail=_4CF5D818-DDA2-40C0-BB2E-921B3BBA4B0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I would like to encourage people to read the client association draft = before monday. = http://tools.ietf.org/html/draft-hunt-oauth-client-association-00.txt = and the related = http://tools.ietf.org/html/draft-hunt-oauth-software-statement-00.txt Most of the draft just focuses on background and taxonomy. If you are = not interested, focus in on the dynamic association section. I believe = you will find this alternate stateless approach to be very simple to = implement and uses a well established pattern. My position is that while the new approach represents a major change to = OIDC implementors, the benefits outweigh the costs as it will make = Connect much easier to support for service providers. The key difference in approaches is that the software statement serves = as a way to lock-down registration profiles that allow servers (and = their policy systems) to recognize different types of client software. = Note that nothing about using software statements prevents developers = from self-asserting registration. Those scenarios can continue to work. = The key benefit to service providers and client developers is that the = number of variations for registration options is dramatically reduced. = The registration becomes a simple assertion swap with any allowable = per-client overrides as an exception rather than the norm. IOW -- client association places different emphasis on what happens = when. Client association assumes software characteristics are known at = packaging time and does not vary widely (from the client side) other = than having to handle different authentication policies of the various = service providers. I've already spent more text here explaining the difference than the = core of the draft takes to explain the registration. So please read the = draft before our discussion on monday. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_4CF5D818-DDA2-40C0-BB2E-921B3BBA4B0F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = would like to encourage people to read the client association draft = before monday. http://tools.ietf.org/html/draft-hunt-oauth-client-association-00.txt= and the related http://tools.ietf.org/html/draft-hunt-oauth-software-statement-00.txt=

Most of the draft just focuses on background and = taxonomy. If you are not interested, focus in on the dynamic association = section. I believe you will find this alternate stateless approach to be = very simple to implement and uses a well established = pattern.

My position is that while the new = approach represents a major change to OIDC implementors, the benefits = outweigh the costs as it will make Connect much easier to support for = service providers.

The key difference in = approaches is that the software statement serves as a way to lock-down = registration profiles that allow servers (and their policy systems) to = recognize different types of client software.   Note that nothing = about using software statements prevents developers from self-asserting = registration.  Those scenarios can continue to work.   The key = benefit to service providers and client developers is that the number of = variations for registration options is dramatically reduced. The = registration becomes a simple assertion swap with any allowable = per-client overrides as an exception rather than the = norm.

IOW -- client association places = different emphasis on what happens when.  Client association = assumes software characteristics are known at packaging time and does = not vary widely (from the client side) other than having to handle = different authentication policies of the various service = providers.

I've already spent more text here = explaining the difference than the core of the draft takes to explain = the registration. So please read the draft before our discussion on = monday.


= --Apple-Mail=_4CF5D818-DDA2-40C0-BB2E-921B3BBA4B0F-- From hannes.tschofenig@gmx.net Fri Nov 1 12:13:59 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7957B11E8126 for ; Fri, 1 Nov 2013 12:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlFplWEEeoWw for ; Fri, 1 Nov 2013 12:13:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2527B11E8179 for ; Fri, 1 Nov 2013 12:13:53 -0700 (PDT) Received: from masham-mac.home ([81.164.176.169]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MC7em-1VTUSe1Gj2-008urn for ; Fri, 01 Nov 2013 20:13:52 +0100 Message-ID: <5273FD6F.3070404@gmx.net> Date: Fri, 01 Nov 2013 20:13:51 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "oauth@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:sbsJOP34YZuhjY6UMbKslIMs4TVsnUo88s81OtDsNWln/VUmd3g KyAxjXw2fMQI/ZLellPrMOM9MNnXngbiffOscQjr8gVPEqtH9jkxSbwVgHDZXDodxB8KFi5 ruUu/zwB632an9ZVDXsGBLUdo160H6s15S3rLvdDpOlPoUein6VHLXIy0E3Prwn8BB+8zqD GfLqJXVslsxFzRhUxnLQA== Subject: [OAUTH-WG] draft-hunt-oauth-software-statement-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 19:13:59 -0000 Hi Phil, Hi Tony, Hi all, regarding this document I believe there are the following questions the group may want to think about: a) Is the lifecycle of software development (Figure 1) common accross several companies? b) The document defines a number of attributes. Are those attributes also used in other deployments? Is their semantic clearly defined so that meaningful actions can be taken when receiving those? c) Is the proposed approach for conveying the software statement acceptable for the group? (currently the information is conveyed as a bearer token encoded as JWT). What would be good to have is two things: * Examples * Text that describes what decisions can be made by the introduction of the software assertions. This text could go into the introduction to provide a motivation about why to use it. Ciao Hannes From hannes.tschofenig@gmx.net Fri Nov 1 12:26:56 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9CB11E813D for ; Fri, 1 Nov 2013 12:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rjM19eux2xW for ; Fri, 1 Nov 2013 12:26:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id CAFDD21E80E8 for ; Fri, 1 Nov 2013 12:26:48 -0700 (PDT) Received: from masham-mac.home ([81.164.176.169]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MEoGY-1VRwME02Pa-00G215 for ; Fri, 01 Nov 2013 20:26:48 +0100 Message-ID: <52740076.7050609@gmx.net> Date: Fri, 01 Nov 2013 20:26:46 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "oauth@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:1ZM7Snw85KXIsl67jPWjFX9+u1ikoSQ8XFPUw1n4B8MkFlCoVzm XaHIe3ASS15uzHV2pwxgCppArwYalbfvFzQgRoabJJ7XETui1tI3kT2f4/t2cG3YU3p+XZJ bvjaaYsi8RMHJLMHc1YhRryfzhlZYh8AxtyBq/AAbWfMnaJnDrVmROQgwUJDlqRgnBxfDmU Xezcw2XzBPMYbDmBm9Bbg== Subject: [OAUTH-WG] draft-ietf-oauth-json-web-token-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 19:26:56 -0000 Hi Mike, Hi all, I was just trying to find out whether version -12 of the JWT spec addresses prior comments and the diff version of the document does not really give that indication. To me it seems that version -12 of the document was published to update -11 in an attempt to create an alignment with the JOSE work. I believe it would be useful to respond to the review comments so that we can be sure that those had been taken into account (or that they had been rejected for a good reason). Here are the comments I have found: * Review by James Manger: http://www.ietf.org/mail-archive/web/oauth/current/msg11905.html * Review by Mishra Prateek: http://www.ietf.org/mail-archive/web/oauth/current/msg12003.html * My own shepherd review: http://www.ietf.org/mail-archive/web/oauth/current/msg12125.html Ciao Hannes From bcampbell@pingidentity.com Fri Nov 1 12:53:43 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFDE11E811D for ; Fri, 1 Nov 2013 12:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lrwd61bjoma for ; Fri, 1 Nov 2013 12:53:39 -0700 (PDT) Received: from na3sys009aog123.obsmtp.com (na3sys009aog123.obsmtp.com [74.125.149.149]) by ietfa.amsl.com (Postfix) with ESMTP id 4899B21F9FA4 for ; Fri, 1 Nov 2013 12:53:36 -0700 (PDT) Received: from mail-ie0-f175.google.com ([209.85.223.175]) (using TLSv1) by na3sys009aob123.postini.com ([74.125.148.12]) with SMTP ID DSNKUnQGwHvOTdqc9XiR1v+YIXWvf0lkZCTo@postini.com; Fri, 01 Nov 2013 12:53:36 PDT Received: by mail-ie0-f175.google.com with SMTP id aq17so8413192iec.34 for ; Fri, 01 Nov 2013 12:53:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=04vhuw6zEfsyVyjmzHFIKxTMcjhpP0aP40tNj5bwHQw=; b=mmVp/8ISJYdRpMDzyT/sCctkzcCPyCRHa7bYka3ldj32fqtjP98NPZGSvsP1KYwc7k 8e73qn1lrNTCtbTLkinrD9isJOEnFSEpFvSEYAFYwtAqbHBTTFcdgHrjtK4PT/NpsClW ItdYljmBfndazCkoChDpceGwcJtwlAVlBZEZpVmY54I26zgTEVe6k/niNzrbu3zCxpIc 2lEKEtps4vE5G4tUlQgNynNjx5eikzZkmhCt/odcLi+3UVo5UVcjjmvwY4cnXxvvi/2V dqigc5hcY9iN7MRY7+CydJTN8c9EY4+x7nC2TkvTy6ZdjOEtmQlJcMZKAPi2HltYax9/ 0DMQ== X-Gm-Message-State: ALoCoQm87woNLzLDIcBJevVZ2YxhDsfNZJ2D7XuuC0SyK504DtNCq4uIGIrRkK+8fDMjyLV+KMg2wmY/+NAaF0GcTlDlCeR3Prk84DkJfyVz1I3po1CELz4UD2G2KlBvlW3PZT0V4bUlX4PZZPxwRWWts0ckVamNKw== X-Received: by 10.50.56.44 with SMTP id x12mr3706431igp.41.1383335615765; Fri, 01 Nov 2013 12:53:35 -0700 (PDT) X-Received: by 10.50.56.44 with SMTP id x12mr3706424igp.41.1383335615608; Fri, 01 Nov 2013 12:53:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.245.233 with HTTP; Fri, 1 Nov 2013 12:53:05 -0700 (PDT) In-Reply-To: <1373E8CE237FCC43BCA36C6558612D2AA3396C@USCHMBX001.nsn-intra.net> References: <1373E8CE237FCC43BCA36C6558612D2AA3396C@USCHMBX001.nsn-intra.net> From: Brian Campbell Date: Fri, 1 Nov 2013 13:53:05 -0600 Message-ID: To: "Tschofenig, Hannes (NSN - FI/Espoo)" Content-Type: multipart/alternative; boundary=089e0158a8faf951f404ea22ebf5 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Next Steps for the JSON Web Token Document X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 19:53:43 -0000 --089e0158a8faf951f404ea22ebf5 Content-Type: text/plain; charset=ISO-8859-1 I just saw http://www.ietf.org/mail-archive/web/oauth/current/msg12218.htmlfrom Hannes noting reviews on draft-ietf-oauth-json-web-token and was surprised that mine wasn't included. So I went looking for it and apparently I didn't actually send it to the list. But I did find it and am including what I wrote and tried but failed to send back in September. Sorry about that. And here it s: Below are my review comments on the JSON Web Token Document that I (had forgotten until reminded by Hannes yesterday) committed to reviewing at the meeting in Berlin. Review of draft-ietf-oauth-json-web-token-11: * The sentence about the suggested pronunciation being 'jot' is in both the intro and the abstract. Seems like just once would be sufficient. * Should "Base64url Encoding" in the Terminology section also mention the omission/prohibition of line wrapping? * References to sections or appendices in other documents often don't have the correct href value. For example, "Base64url Encoding" in the Terminology section has this problem for Section 3.2, which should point to RFC 4648 and Appendix C, which should go to JWS but both refer to the local document. There are many other instances of the same issue. I assume this is due to some tool in the xml2rfc or I-D upload process (and I know I have it in some of the drafts I author) but is this the kind of thing that the RFC editor will take care of? * I continue to struggle to understand how the type and content type Header parameters and the type claim can or will be used in a meaningful and reliable way. I can't help but wonder if it couldn't be simplified. For example. what if we only had the cty header and defined a cty value for a JWT Claims Set - couldn't all the same things be conveyed? * There are a number of the reserved claims that say the use of the claim is OPTIONAL while also stating that the "JWT MUST be rejected" if some condition about the claim doesn't hold. There seems to be some potential ambiguity here regarding whether (in the absence of tighter context-dependent requirements, which is what generalized JWT libraries need to be built for) the optionality applies only to the producer or also to the consumer of a JWT. My guess is that the claims are optional to include for the producer but, if they are present, they must be validated by the consumer and the JWT must be rejected if whatever condition isn't satisfied. Do I have that right? Regardless, I think there is some ambiguity as currently written that should be clarified. Note that some of these comments relate to or even apply directly to JWS and JWE as well. Which I suppose underscores the point James made a while ago about progressing this document so far ahead of the JOSE drafts. On Tue, Sep 10, 2013 at 8:26 AM, Tschofenig, Hannes (NSN - FI/Espoo) < hannes.tschofenig@nsn.com> wrote: > Hi again, > > I also checked the minutes from IETF#87 regarding the JWT and here are the > action items: > > ** I issued a WGLC, as discussed during the meeting: > http://www.ietf.org/mail-archive/web/oauth/current/msg11894.html > > ** We got some reviews from James, and Prateek. Thanks, guys! > Here are the reviews: > http://www.ietf.org/mail-archive/web/oauth/current/msg11905.html (James) > http://www.ietf.org/mail-archive/web/oauth/current/msg12003.html (Prateek) > > During the meeting a few others, namely Torsten, Karen, Paul Hoffman, and > Brian volunteered to provide their review comments. Please send your review > to the list. > > ** I will have to do my shepherd write-up as well. > > Ciao > Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --089e0158a8faf951f404ea22ebf5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I just saw http://www.ietf.org/mail-archive/web/oau= th/current/msg12218.html from Hannes noting reviews on draft-ietf-oauth= -json-web-token and was surprised that mine wasn't included. So I went = looking for it and apparently I didn't actually send it to the list. Bu= t I did find it and am including what I wrote and tried but failed to send = back in September. Sorry about that.

And here it s:

Below are my review comments on the JSON Web Tok= en Document that I (had forgotten until reminded by Hannes yesterday= ) committed to reviewing at the meeting in Berlin.

Review of draft-ietf-oauth-json-web-token-11:

* The sentence about the suggested pronunciation being 'jot' is= in=20 both the intro and the abstract. Seems like just once would be=20 sufficient.

* Should "Base64url Encoding" in the Terminolo= gy section also mention the omission/prohibition of line wrapping?

* References to sections or appendices in other documents often=20 don't have the correct href value.=A0 For example, "Base64url Enco= ding" in the Terminology section has this problem for Section 3.2, which should=20 point to RFC 4648 and Appendix C, which should go to JWS but both refer=20 to the local document. There are many other instances of the same issue. I assume this is due to some tool in the xml2rfc or I-D upload process=20 (and I know I have it in some of the drafts I author) but is this the=20 kind of thing that the RFC editor will take care of?

* I continue to struggle to understand how the type and content type Header parameters and the type claim can or will be used in a=20 meaningful and reliable way.=A0 I can't help but wonder if it couldn= 9;t be=20 simplified. For example. what if we only had the cty header and defined a cty value for a JWT Claims Set - couldn't all = the same things be conveyed?

* There are a number of the reserved claims that say the use of the cla= im is OPTIONAL while also stating that the "JWT MUST be rejected" if some condition about the claim doesn't hold.= There seems to be some potential ambiguity here regarding whether (in the=20 absence of tighter context-dependent requirements, which is what=20 generalized JWT libraries need to be built for) the= optionality applies only to the producer or also to the consumer of a JWT. My guess is that the claims are optional to include for the producer=20 but, if they are present, they must be validated by the consumer and the JWT must be rejected if whatever condition=20 isn't satisfied. Do I have that right? Regardless, I think there is som= e ambiguity as currently written that should be clarified.

Note that some of these comments relate to or even apply directly to JWS and JWE as well. Which I suppose underscores the point James made a while ago about progressing this document so far ahead of the JOSE=20 drafts.
<= /div>



On Tue, Sep 10, 2013 at 8:26 AM, Tschofenig, Hannes (NSN - FI/Espoo) <hannes.tschofenig@nsn.com> wrote:
Hi again,

I also checked the minutes from IETF#87 regarding the JWT and here are the = action items:

** I issued a WGLC, as discussed during the meeting: ht= tp://www.ietf.org/mail-archive/web/oauth/current/msg11894.html

** We got some reviews from James, and Prateek. Thanks, guys!
Here are the reviews:
http://www.ietf.org/mail-archive/web/oauth/current/msg1= 1905.html (James)
http://www.ietf.org/mail-archive/web/oauth/current/msg1= 2003.html (Prateek)

=A0During the meeting a few others, namely Torsten, Karen, Paul Hoffman, an= d Brian volunteered to provide their review comments. Please send your revi= ew to the list.

** I will have to do my shepherd write-up as well.

Ciao
Hannes

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--089e0158a8faf951f404ea22ebf5-- From phil.hunt@oracle.com Fri Nov 1 12:55:08 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A068F11E81A4 for ; Fri, 1 Nov 2013 12:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.268 X-Spam-Level: X-Spam-Status: No, score=-6.268 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3G-Nbg75MpGM for ; Fri, 1 Nov 2013 12:55:03 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 86DFC11E811D for ; Fri, 1 Nov 2013 12:55:03 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA1JsxPv010601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Nov 2013 19:55:00 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA1Jswex004678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Nov 2013 19:54:59 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA1Jswef025962; Fri, 1 Nov 2013 19:54:58 GMT Received: from [192.168.1.12] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Nov 2013 12:54:58 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <5273FD6F.3070404@gmx.net> Date: Fri, 1 Nov 2013 12:54:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7CBADC8F-E81D-453B-92FA-CADFDA0AD37D@oracle.com> References: <5273FD6F.3070404@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1510) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-hunt-oauth-software-statement-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 19:55:08 -0000 See below... Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-11-01, at 12:13 PM, Hannes Tschofenig = wrote: > Hi Phil, Hi Tony, Hi all, >=20 > regarding this document I believe there are the following questions = the group may want to think about: >=20 > a) Is the lifecycle of software development (Figure 1) common accross = several companies? We are trying to be generic. What we are trying to do is take the old = model where a developer would register with a Facebook, a Google, = whatever and apply it to what happens to open source API and commercial = API scenarios where software is deployed in many locations (not just a = single cloud provider). >=20 > b) The document defines a number of attributes. Are those attributes = also used in other deployments? Is their semantic clearly defined so = that meaningful actions can be taken when receiving those? The attributes come from Dynamic Registration. Only thing new here is = software_id and software_version.=20 >=20 > c) Is the proposed approach for conveying the software statement = acceptable for the group? > (currently the information is conveyed as a bearer token encoded as = JWT). John Bradley's JWT token is similar, but I think they have different = characteristics in the way they are used. I'd like to here John present = this at the meeting before I attempt to try and compare them. This is = something I'd like to work on together. >=20 > What would be good to have is two things: >=20 > * Examples >=20 > * Text that describes what decisions can be made by the introduction = of the software assertions. This text could go into the introduction to = provide a motivation about why to use it. I am open to a lot of change her. If anything, my feeling is that if = anything we should cut the drafts back down to the raw normative text. = It is my feeling there is too much explanatory text that drives the = perception that the proposal is complex. Yet this boils down to 3 = methods: Static - do what you are doing now if that works. Dynamic - Swap a software statement (shared by all instances of the same = app) for an individual client assertion (assertion swap) Transient - just pass your software_id (or maybe it should be software = statement) as you client_id >=20 > Ciao > Hannes > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Fri Nov 1 12:56:50 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244CA11E813D for ; Fri, 1 Nov 2013 12:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.278 X-Spam-Level: X-Spam-Status: No, score=-6.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jWORPiIOEQJ for ; Fri, 1 Nov 2013 12:56:45 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id E220521E80E8 for ; Fri, 1 Nov 2013 12:56:32 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA1JuMhU012189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Nov 2013 19:56:22 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA1JuL1K009017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Nov 2013 19:56:22 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA1JuLKD009002; Fri, 1 Nov 2013 19:56:21 GMT Received: from [192.168.1.12] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Nov 2013 12:56:21 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <5273FA71.4000500@gmx.net> Date: Fri, 1 Nov 2013 12:56:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1D4A7D8A-A532-4368-B0E0-87B73B57F1EC@oracle.com> References: <5273FA71.4000500@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1510) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-hunt-oauth-client-association-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 19:56:50 -0000 Hannes, Great timing! This is an aspect that I think deserves more discussion. One of the = challenges was to draw a clear line of distinction between transient and = dynamic. =20 Transient clients are really meant for javascript clients that decide to = connect to a particular end-point on the fly. Note you can still have = "static" javascript clients that are hard coded to connect and have = already received a client_id through an out-of-band process. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-11-01, at 12:01 PM, Hannes Tschofenig = wrote: > Hi Phil, Hi Tony, Hi all, >=20 > I re-read the document and I believe the most important concept it = introduces is the classification of different associations, namely into = 'static', 'dynamic', and 'transient'. This is certainly something = worthwhile to discuss during the meeting and to ensure that it is well = understood, and that there are only these three classes (rather than two = or four). >=20 > The description in the introduction makes the differentiation between = the three concepts mostly based on how the endpoints are configured in = the application. >=20 > With the static association the endpoint is hard-coded into the = software during the development time. It cannot be changed. With the two = other cases the endpoint can be changed. As such, the difference between = the 'dynamic', and 'transient' association seems to be in the terms of = how long the lifetime of the association. Now, what exactly is the = lifetime of an association? Is the lifetime of the association = understood as the lifetime of the configured endpoint identifier? >=20 > Then, when I re-read the text in Section 1 again then I suddenly get = the impression that the lifetime of the association actually does not = matter but instead the difference is rather whether the client is public = or confidential. Is that true? >=20 > If it isn't true that this is the feature that makes the distinction = between 'dynamic', and 'transient' then the notion of "public" vs. = "confidential" client isn't too important for the rest of the document. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Fri Nov 1 13:13:10 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0422F21E80B7 for ; Fri, 1 Nov 2013 13:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97upLKqsNIdE for ; Fri, 1 Nov 2013 13:13:05 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0B10221E80E1 for ; Fri, 1 Nov 2013 13:13:04 -0700 (PDT) Received: from masham-mac.home ([81.164.176.169]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MMBun-1VZKHi1wTt-00864E for ; Fri, 01 Nov 2013 21:13:03 +0100 Message-ID: <52740B4D.6060404@gmx.net> Date: Fri, 01 Nov 2013 21:13:01 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Brian Campbell References: <1373E8CE237FCC43BCA36C6558612D2AA3396C@USCHMBX001.nsn-intra.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:d/Mjr8IXkWaoSXy0IZ3iQ8n9cJ3TtYmNZ8fYF6zBgDasadK7li/ 4MktR9BJG+1KCuPGGPiSbPsxEA+A0Ne3PtjV9WVpX9yBupDjzYucOiL+0yhJ5jzbNhmRnO9 9FDzfkU672xlxu8qf+RAOSOLDTUoaq6K9zmrUumQorsGL6ZUWablenVC2rCfQpY//ybm/fl AMov25DKuedK22Bsb9AJQ== Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Next Steps for the JSON Web Token Document X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 20:13:10 -0000 Thank you for your review, Brian. Am 01.11.13 20:53, schrieb Brian Campbell: > I just saw > http://www.ietf.org/mail-archive/web/oauth/current/msg12218.html from > Hannes noting reviews on draft-ietf-oauth-json-web-token and was > surprised that mine wasn't included. So I went looking for it and > apparently I didn't actually send it to the list. But I did find it and > am including what I wrote and tried but failed to send back in > September. Sorry about that. > > And here it s: > > Below are my review comments on the JSON Web Token Document that I (had > forgotten until reminded by Hannes yesterday) committed to reviewing at > the meeting in Berlin. > > Review of draft-ietf-oauth-json-web-token-11: > > * The sentence about the suggested pronunciation being 'jot' is in both > the intro and the abstract. Seems like just once would be sufficient. > > * Should "Base64url Encoding" in the Terminology section also mention > the omission/prohibition of line wrapping? > > * References to sections or appendices in other documents often don't > have the correct href value. For example, "Base64url Encoding" in the > Terminology section has this problem for Section 3.2, which should point > to RFC 4648 and Appendix C, which should go to JWS but both refer to the > local document. There are many other instances of the same issue. I > assume this is due to some tool in the xml2rfc or I-D upload process > (and I know I have it in some of the drafts I author) but is this the > kind of thing that the RFC editor will take care of? > > * I continue to struggle to understand how the type and content type > Header parameters and the type claim can or will be used in a meaningful > and reliable way. I can't help but wonder if it couldn't be simplified. > For example. what if we only had the cty header and defined a cty value > for a JWT Claims Set - couldn't all the same things be conveyed? > > * There are a number of the reserved claims that say the use of the > claim is OPTIONAL while also stating that the "JWT MUST be rejected" if > some condition about the claim doesn't hold. There seems to be some > potential ambiguity here regarding whether (in the absence of tighter > context-dependent requirements, which is what generalized JWT libraries > need to be built for) the optionality applies only to the producer or > also to the consumer of a JWT. My guess is that the claims are optional > to include for the producer but, if they are present, they must be > validated by the consumer and the JWT must be rejected if whatever > condition isn't satisfied. Do I have that right? Regardless, I think > there is some ambiguity as currently written that should be clarified. > > Note that some of these comments relate to or even apply directly to JWS > and JWE as well. Which I suppose underscores the point James made a > while ago about progressing this document so far ahead of the JOSE drafts. > > > > On Tue, Sep 10, 2013 at 8:26 AM, Tschofenig, Hannes (NSN - FI/Espoo) > > wrote: > > Hi again, > > I also checked the minutes from IETF#87 regarding the JWT and here > are the action items: > > ** I issued a WGLC, as discussed during the meeting: > http://www.ietf.org/mail-archive/web/oauth/current/msg11894.html > > ** We got some reviews from James, and Prateek. Thanks, guys! > Here are the reviews: > http://www.ietf.org/mail-archive/web/oauth/current/msg11905.html (James) > http://www.ietf.org/mail-archive/web/oauth/current/msg12003.html > (Prateek) > > During the meeting a few others, namely Torsten, Karen, Paul > Hoffman, and Brian volunteered to provide their review comments. > Please send your review to the list. > > ** I will have to do my shepherd write-up as well. > > Ciao > Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From hannes.tschofenig@gmx.net Fri Nov 1 13:17:53 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EACB611E8131 for ; Fri, 1 Nov 2013 13:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOLpez-n+tfF for ; Fri, 1 Nov 2013 13:17:49 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2A26011E811D for ; Fri, 1 Nov 2013 13:17:49 -0700 (PDT) Received: from masham-mac.home ([81.164.176.169]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LlUZz-1WBOrj0uAx-00bOX8 for ; Fri, 01 Nov 2013 21:17:48 +0100 Message-ID: <52740C6B.8080000@gmx.net> Date: Fri, 01 Nov 2013 21:17:47 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Phil Hunt References: <5273FD6F.3070404@gmx.net> <7CBADC8F-E81D-453B-92FA-CADFDA0AD37D@oracle.com> In-Reply-To: <7CBADC8F-E81D-453B-92FA-CADFDA0AD37D@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ZI8YTUFy5aukjkX4VrP26SFtWsHfRDVgV3n59JNrlZ6/BHaTVr5 SEBnOkw2tYnsfFKdSyPypZuQPWqWXYivcAH37MTQWqkL5KaAaeeMqy9TkXDgts4fmlXYN6J GWviFHbD6QCwLfIgSftQUZ8OzBNsOqvLN+bwi3NYCXdrTv7DEFO0i6z2EAmzcJ9LSZ4LZcW SFKyr6Tic4ZVKuO5zPvVg== Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-hunt-oauth-software-statement-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 20:17:54 -0000 Hi Phil, thanks for the quick response. Am 01.11.13 20:54, schrieb Phil Hunt: > See below... Phil > > @independentid www.independentid.com phil.hunt@oracle.com > > On 2013-11-01, at 12:13 PM, Hannes Tschofenig > wrote: > >> Hi Phil, Hi Tony, Hi all, >> >> regarding this document I believe there are the following questions >> the group may want to think about: >> >> a) Is the lifecycle of software development (Figure 1) common >> accross several companies? > > We are trying to be generic. What we are trying to do is take the old > model where a developer would register with a Facebook, a Google, > whatever and apply it to what happens to open source API and > commercial API scenarios where software is deployed in many locations > (not just a single cloud provider). Certainly makes sense. I am just saying that it would be good if there are others in the group who say that the described model lines up with their practices. You never know but their practices may actually be different. >> >> b) The document defines a number of attributes. Are those >> attributes also used in other deployments? Is their semantic >> clearly defined so that meaningful actions can be taken when >> receiving those? > > The attributes come from Dynamic Registration. Only thing new here > is software_id and software_version. I didn't realize that. Maybe that's worthwhile to highlight. So, the question would then be to the group whether the two newly defined attributes are sufficient and well-defined. The description was good for me. >> >> c) Is the proposed approach for conveying the software statement >> acceptable for the group? (currently the information is conveyed as >> a bearer token encoded as JWT). > > John Bradley's JWT token is similar, but I think they have different > characteristics in the way they are used. I'd like to here John > present this at the meeting before I attempt to try and compare them. > This is something I'd like to work on together. Thanks; that might be useful. I personally don't have a preference here but getting feedback from the group would be good. >> >> What would be good to have is two things: >> >> * Examples >> >> * Text that describes what decisions can be made by the >> introduction of the software assertions. This text could go into >> the introduction to provide a motivation about why to use it. > > I am open to a lot of change her. If anything, my feeling is that if > anything we should cut the drafts back down to the raw normative > text. It is my feeling there is too much explanatory text that > drives the perception that the proposal is complex. Yet this boils > down to 3 methods: > > Static - do what you are doing now if that works. Dynamic - Swap a > software statement (shared by all instances of the same app) for an > individual client assertion (assertion swap) Transient - just pass > your software_id (or maybe it should be software statement) as you > client_id I like that short summary. That should be something for the intro Ciao Hannes > >> >> Ciao Hannes _______________________________________________ OAuth >> mailing list OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From hannes.tschofenig@gmx.net Fri Nov 1 13:23:16 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C557911E814F for ; Fri, 1 Nov 2013 13:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQsTlYbgpD4b for ; Fri, 1 Nov 2013 13:23:12 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 07B2D11E811D for ; Fri, 1 Nov 2013 13:23:12 -0700 (PDT) Received: from masham-mac.home ([81.164.176.169]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lta9E-1VkHF50rTA-010upz for ; Fri, 01 Nov 2013 21:23:11 +0100 Message-ID: <52740DAD.9030102@gmx.net> Date: Fri, 01 Nov 2013 21:23:09 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Phil Hunt References: <5273FA71.4000500@gmx.net> <1D4A7D8A-A532-4368-B0E0-87B73B57F1EC@oracle.com> In-Reply-To: <1D4A7D8A-A532-4368-B0E0-87B73B57F1EC@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:I/SwcaWOxsn6b7bnhuLajkd1bWy84f8bEH/2mRpiLxIXLheJmFm B3tuhMBEcN8MUk5DJWGd8L3N3W+5ukHaBZe7Z8RZ7hf7FiCIpyinkVCOUlaO/e/jPfYjmvc uCXJHI/wZ7SxF56ysMfIFShVKblLEq1af0e+uWW5mOnVvLZiOSk+iVVyDdYA9sTT9TXaKNF Cy1nd6+XE9npmlSb1oI6g== Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-hunt-oauth-client-association-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 20:23:16 -0000 Hi Phil, We definitely have to figure out how the differentiation is made so that a developer (or someone who deploys the technology) understands the scenario they are in and what the implications are. At the moment I would struggle a bit. Using examples is certainly a good idea, like you did below. There are, however, quickly challenges. For example, in the JavaScript case below you can imagine a developer of a smart phone app who uses JavaScript but then packages the application (using PhoneGap), which makes it behave very much like a native app. And, as you say below, the notion of whether the endpoint is configured upfront (during development time) or dynamically configured may not necessarily matter. It definitely makes sense to discuss this during the meeting and real-world examples may help. Ciao Hannes Am 01.11.13 20:56, schrieb Phil Hunt: > Hannes, > > Great timing! > > This is an aspect that I think deserves more discussion. One of the > challenges was to draw a clear line of distinction between transient > and dynamic. > > Transient clients are really meant for javascript clients that decide > to connect to a particular end-point on the fly. Note you can still > have "static" javascript clients that are hard coded to connect and > have already received a client_id through an out-of-band process. > > Phil > > @independentid www.independentid.com phil.hunt@oracle.com > > On 2013-11-01, at 12:01 PM, Hannes Tschofenig > wrote: > >> Hi Phil, Hi Tony, Hi all, >> >> I re-read the document and I believe the most important concept it >> introduces is the classification of different associations, namely >> into 'static', 'dynamic', and 'transient'. This is certainly >> something worthwhile to discuss during the meeting and to ensure >> that it is well understood, and that there are only these three >> classes (rather than two or four). >> >> The description in the introduction makes the differentiation >> between the three concepts mostly based on how the endpoints are >> configured in the application. >> >> With the static association the endpoint is hard-coded into the >> software during the development time. It cannot be changed. With >> the two other cases the endpoint can be changed. As such, the >> difference between the 'dynamic', and 'transient' association seems >> to be in the terms of how long the lifetime of the association. >> Now, what exactly is the lifetime of an association? Is the >> lifetime of the association understood as the lifetime of the >> configured endpoint identifier? >> >> Then, when I re-read the text in Section 1 again then I suddenly >> get the impression that the lifetime of the association actually >> does not matter but instead the difference is rather whether the >> client is public or confidential. Is that true? >> >> If it isn't true that this is the feature that makes the >> distinction between 'dynamic', and 'transient' then the notion of >> "public" vs. "confidential" client isn't too important for the rest >> of the document. >> >> Ciao Hannes >> >> >> _______________________________________________ OAuth mailing list >> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth > From hannes.tschofenig@gmx.net Fri Nov 1 13:52:13 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F46611E816D for ; Fri, 1 Nov 2013 13:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+l9GXbhqkU8 for ; Fri, 1 Nov 2013 13:52:07 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2388011E8166 for ; Fri, 1 Nov 2013 13:52:05 -0700 (PDT) Received: from masham-mac.home ([81.164.176.169]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MK4fR-1VbWLo0JRl-001PPf for ; Fri, 01 Nov 2013 21:52:05 +0100 Message-ID: <52741472.8020405@gmx.net> Date: Fri, 01 Nov 2013 21:52:02 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "oauth@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:rHvSRvIHQmPYiwV/cGY/2JAM0xeg50hDLqoFuedwFB1HtWBS+no yQl1RFc+u5vO0AD5kzwsra2b+ii95fJhROY03Z7j1ex37/qx89rC5cP2EuPo8XUJ2nR+owj eU4KgEsrEq4G2rVGmP+qU3JMi45ROlWaPsb0yw/Oxda4m+GeYx03ZQV6m1MNxOzfkkKGQJ0 nzGDQyxxZz+j/MkxGekBw== Subject: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 20:52:13 -0000 Hi Mike, Hi all, I read through draft-ietf-oauth-jwt-bearer-06 in an attempt to find out whether I would be able to produce an interoperable implementation from this document. A few minor things came to my mind: Section 3: You write: " 1. The JWT MUST contain an "iss" (issuer) claim that contains a unique identifier for the entity that issued the JWT. Issuer values SHOULD be compared using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986 [RFC3986], unless otherwise specified by the application. " What is not stated here is what are the two values that are compared against each other. One value is the issuer claim from the JWT and the other value is the, I guess, an entry from a whitelist of trusted issuers. You write: " 2. The JWT MUST contain a "sub" (subject) claim identifying the subject of the transaction. The subject MAY identify the resource owner for whom the access token is being requested. A. When using a JWT as an authorization grant, the subject SHOULD identify an authorized accessor for whom the access token is being requested (typically the resource owner, or an authorized delegate). B. For client authentication, the subject MUST be the "client_id" of the OAuth client. " Should this rather read: " 2. The JWT MUST contain a "sub" (subject) claim identifing the principal that is the subject of the JWT. Two cases need to be differentiated: A. For the authorization grant, the subject SHOULD identify an authorized accessor for whom the access token is being requested (typically the resource owner, or an authorized delegate). B. For client authentication, the subject MUST be the "client_id" of the OAuth client. " Why isn't the SHOULD under (A) actually a MUST? Then, the current text in A is so fuzzy that it actually doesn't allow someone to create a test case to test whether an implementation is interoperable or not. With B the situation is different. Is there something else we can say for A? You write: " 3. The JWT MUST contain an "aud" (audience) claim containing a value that identifies the authorization server as an intended audience. The token endpoint URL of the authorization server MAY be used as a value for an "aud" element to identify the authorization server as an intended audience of the JWT. JWTs that do not identify the authorization server as an intended audience MUST be rejected. Audience values SHOULD be compared using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986 [RFC3986], unless otherwise specified by the application. " If the endpoint URL of the AS is not used then what else? Wouldn't it be useful to say "The token endpoint URL of the authorization server MUST be used as a value for an "aud" element to identify the authorization server as an intended audience of the JWT."? Then, I have a suggestion for re-phrasing this sentence from : " Audience values SHOULD be compared using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986 [RFC3986], unless otherwise specified by the application. " to: " In the absence of an application profile standard specifying otherwise, a compliant JWT Bearer application MUST compare the audience values using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986 [RFC3986]. " The same can actually be applied to the issuer claim as well. Given that the JWT had been updated to align it with the JOSE work I suspect that this document also requires an update. Section 5 about "Interoperability Considerations" says: " Specific items that require agreement are as follows: values for the issuer and audience identifiers, the location of the token endpoint, and the key used to apply and verify the digital signature or keyed message digest over the JWT. " I believe that this list is not correct. What is needed is: * At the authorization server there needs to be a whitelist of trusted issuers. For a succesful protocol run the JWT needs to be created by an issuer who is in the whitelist. * Along with the entry in the whitelist of trusted issuers needs to be a key. There is no new endpoint URL defined by this document. As such, I wouldn't mention those. I also do not think that the audience identifier needs to be agreed if you define it as the token endpoint URL of the authorization server (as I suggested above). Ciao Hannes From phil.hunt@oracle.com Fri Nov 1 14:25:12 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 182FF11E8181 for ; Fri, 1 Nov 2013 14:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.287 X-Spam-Level: X-Spam-Status: No, score=-6.287 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVuLK8CTSDUl for ; Fri, 1 Nov 2013 14:25:07 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id DFBE511E8160 for ; Fri, 1 Nov 2013 14:25:06 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA1LP3N4015365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Nov 2013 21:25:03 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA1LP2C9017387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Nov 2013 21:25:03 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA1LP2QR017378; Fri, 1 Nov 2013 21:25:02 GMT Received: from [192.168.1.12] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Nov 2013 14:25:02 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <52740C6B.8080000@gmx.net> Date: Fri, 1 Nov 2013 14:24:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5273FD6F.3070404@gmx.net> <7CBADC8F-E81D-453B-92FA-CADFDA0AD37D@oracle.com> <52740C6B.8080000@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-hunt-oauth-software-statement-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 21:25:12 -0000 Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-11-01, at 1:17 PM, Hannes Tschofenig = wrote: > Hi Phil, >=20 > thanks for the quick response. >=20 >=20 > Am 01.11.13 20:54, schrieb Phil Hunt: >> See below... Phil >>=20 >> @independentid www.independentid.com phil.hunt@oracle.com >>=20 >> On 2013-11-01, at 12:13 PM, Hannes Tschofenig >> wrote: >>=20 >>> Hi Phil, Hi Tony, Hi all, >>>=20 >>> regarding this document I believe there are the following questions >>> the group may want to think about: >>>=20 >>> a) Is the lifecycle of software development (Figure 1) common >>> accross several companies? >>=20 >> We are trying to be generic. What we are trying to do is take the old >> model where a developer would register with a Facebook, a Google, >> whatever and apply it to what happens to open source API and >> commercial API scenarios where software is deployed in many locations >> (not just a single cloud provider). >=20 > Certainly makes sense. I am just saying that it would be good if there = are others in the group who say that the described model lines up with = their practices. You never know but their practices may actually be = different. Hmmm=85. not sure what granularity you are after. I am just describing = what is essentially a "federated" model for registration that works for = developers who have no prior relationship with the service providers = that deploy a particular API. Nothing more. One way to look at this is that Software Statements preserve the current = methodology of the client developer registering with the developer = registration service for an API -- usually that would be the = organization that controls/revises/updates the API definition. In = commercial APIs that would be the vendor, in open APIs, it would be the = consortium or the open source project. In OpenID Connect for example, = it could be the OIDF or someone like the OIX since OIX is helping to = vet/whitelist IDPs. Finally, if no organization is available to provide the developer = software statement, the developer can always self-assert. In a sense = this becomes similar to dyn reg now. Except with one major difference. = All copies of the developer's client will still use the same assertion = and the registration profile is "locked". =20 You could even go to per instance assertions where the developer could = decide to have the client generate on the fly if their use case really = does demand completely different registration per client instance -- = I've yet to see a valid use case, but this would still be possible. IOW -- this is no different from other federation models where AS = service providers decide to trust different assertion "roots" or = specific assertions as needed. A well worn model. =3D=3D=3D> Any lifecycle model is possible! >=20 >>>=20 >>> b) The document defines a number of attributes. Are those >>> attributes also used in other deployments? Is their semantic >>> clearly defined so that meaningful actions can be taken when >>> receiving those? >>=20 >> The attributes come from Dynamic Registration. Only thing new here >> is software_id and software_version. >=20 > I didn't realize that. Maybe that's worthwhile to highlight. >=20 > So, the question would then be to the group whether the two newly = defined attributes are sufficient and well-defined. The description was = good for me. My understanding is that dyn reg has these attributes as well (so they = are no longer new). It may be that software statement's attributes need = to be updated to reflect the current dyn reg phrasing. >=20 >>>=20 >>> c) Is the proposed approach for conveying the software statement >>> acceptable for the group? (currently the information is conveyed as >>> a bearer token encoded as JWT). >>=20 >> John Bradley's JWT token is similar, but I think they have different >> characteristics in the way they are used. I'd like to here John >> present this at the meeting before I attempt to try and compare them. >> This is something I'd like to work on together. >=20 > Thanks; that might be useful. I personally don't have a preference = here but getting feedback from the group would be good. >=20 >=20 >>>=20 >>> What would be good to have is two things: >>>=20 >>> * Examples >>>=20 >>> * Text that describes what decisions can be made by the >>> introduction of the software assertions. This text could go into >>> the introduction to provide a motivation about why to use it. >>=20 >> I am open to a lot of change her. If anything, my feeling is that if >> anything we should cut the drafts back down to the raw normative >> text. It is my feeling there is too much explanatory text that >> drives the perception that the proposal is complex. Yet this boils >> down to 3 methods: >>=20 >> Static - do what you are doing now if that works. Dynamic - Swap a >> software statement (shared by all instances of the same app) for an >> individual client assertion (assertion swap) Transient - just pass >> your software_id (or maybe it should be software statement) as you >> client_id >=20 > I like that short summary. That should be something for the intro >=20 > Ciao > Hannes >=20 >>=20 >>>=20 >>> Ciao Hannes _______________________________________________ OAuth >>> mailing list OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 From phil.hunt@oracle.com Fri Nov 1 15:02:46 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9910111E8136 for ; Fri, 1 Nov 2013 15:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.296 X-Spam-Level: X-Spam-Status: No, score=-6.296 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfLDai7wf+eu for ; Fri, 1 Nov 2013 15:02:41 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id D600211E8143 for ; Fri, 1 Nov 2013 15:02:40 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA1M2bQR016660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Nov 2013 22:02:37 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA1M2Z6k020124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Nov 2013 22:02:35 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA1M2Ze9017030; Fri, 1 Nov 2013 22:02:35 GMT Received: from [192.168.1.12] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Nov 2013 15:02:35 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <52740DAD.9030102@gmx.net> Date: Fri, 1 Nov 2013 15:02:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5273FA71.4000500@gmx.net> <1D4A7D8A-A532-4368-B0E0-87B73B57F1EC@oracle.com> <52740DAD.9030102@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-hunt-oauth-client-association-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 22:02:46 -0000 I think for the client types, the trick is to try to make it restrictive = enough so there's no second-guessing the client developer has to do = about what SPs will accept. The line I was drawing was for = implicit/javascript clients in the current draft. We could open it to a simple decision for the client developer. If they = think they will need an instance specific client_id from service = endpoints, then they need to use dynamic registration. Otherwise = transient registration could be used for on-the-fly transient = associations - which are still public clients. My assessment was we could keep transient restricted to = implicit/javascript only - making the choice very clear. But I'd love = to hear if someone has a case where they think transient fits a client = doing one of the other authorization flows (the broader case). BTW=85.this is why the client association draft is in fact so long. = There is considerable text discussing the classifications and their = differences. Looking at it now, I'm starting to feel stricter "normative" text (MUSTs = & SHOULDS) and less fuzzy explanation and/or examples might actually be = better for inter-op and perceived simplicity/clarity. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-11-01, at 1:23 PM, Hannes Tschofenig = wrote: > Hi Phil, >=20 > We definitely have to figure out how the differentiation is made so = that > a developer (or someone who deploys the technology) understands the > scenario they are in and what the implications are. At the moment I > would struggle a bit. >=20 > Using examples is certainly a good idea, like you did below. There = are, > however, quickly challenges. For example, in the JavaScript case below > you can imagine a developer of a smart phone app who uses JavaScript = but > then packages the application (using PhoneGap), which makes it behave > very much like a native app. >=20 > And, as you say below, the notion of whether the endpoint is = configured upfront (during development time) or dynamically configured = may not necessarily matter. >=20 > It definitely makes sense to discuss this during the meeting and = real-world examples may help. >=20 > Ciao > Hannes >=20 > Am 01.11.13 20:56, schrieb Phil Hunt: >> Hannes, >>=20 >> Great timing! >>=20 >> This is an aspect that I think deserves more discussion. One of the >> challenges was to draw a clear line of distinction between transient >> and dynamic. >>=20 >> Transient clients are really meant for javascript clients that decide >> to connect to a particular end-point on the fly. Note you can still >> have "static" javascript clients that are hard coded to connect and >> have already received a client_id through an out-of-band process. >>=20 >> Phil >>=20 >> @independentid www.independentid.com phil.hunt@oracle.com >>=20 >> On 2013-11-01, at 12:01 PM, Hannes Tschofenig >> wrote: >>=20 >>> Hi Phil, Hi Tony, Hi all, >>>=20 >>> I re-read the document and I believe the most important concept it >>> introduces is the classification of different associations, namely >>> into 'static', 'dynamic', and 'transient'. This is certainly >>> something worthwhile to discuss during the meeting and to ensure >>> that it is well understood, and that there are only these three >>> classes (rather than two or four). >>>=20 >>> The description in the introduction makes the differentiation >>> between the three concepts mostly based on how the endpoints are >>> configured in the application. >>>=20 >>> With the static association the endpoint is hard-coded into the >>> software during the development time. It cannot be changed. With >>> the two other cases the endpoint can be changed. As such, the >>> difference between the 'dynamic', and 'transient' association seems >>> to be in the terms of how long the lifetime of the association. >>> Now, what exactly is the lifetime of an association? Is the >>> lifetime of the association understood as the lifetime of the >>> configured endpoint identifier? >>>=20 >>> Then, when I re-read the text in Section 1 again then I suddenly >>> get the impression that the lifetime of the association actually >>> does not matter but instead the difference is rather whether the >>> client is public or confidential. Is that true? >>>=20 >>> If it isn't true that this is the feature that makes the >>> distinction between 'dynamic', and 'transient' then the notion of >>> "public" vs. "confidential" client isn't too important for the rest >>> of the document. >>>=20 >>> Ciao Hannes >>>=20 >>>=20 >>> _______________________________________________ OAuth mailing list >>> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 From jmandel@gmail.com Fri Nov 1 15:42:36 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9181411E80E9 for ; Fri, 1 Nov 2013 15:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odMRbxEmadRI for ; Fri, 1 Nov 2013 15:42:35 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4708F11E8136 for ; Fri, 1 Nov 2013 15:42:35 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id i4so5145974oah.4 for ; Fri, 01 Nov 2013 15:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=p9jfuHN7nzEmdEDglFyTEn5YqW+N3wNh/M2FxjWuskk=; b=ZF2USVlmYF3GfOMP3OHeUti3tDmJolXHdD8452e0FXt1oXdFgmavDCjfC2MeaZBHv8 DSeMm7wuK8IR2tdSBjnQwxXJaOMV67YMlizyc3S0Yo0pqbztH+a0jVMMQ3EhC1eq9XkJ QfodAWsK1P+iqi5/99BMi8Co5w3O0fE7u2JGbNkyMn7BAy3doWlCk/F32kxYDGvyjAFg /8sIriCwzluPxLLAMEGgSwKEycIuNjcsDYpgIi7Se2atsRBiwRD0EdFkNglrPWgFVuKp Bul0clcd9L9EqPDIO/fiWX9Zgve/vXcgFHnwbE1JIh4/ySOATielvyYA4PKeiwMXYB19 1SbA== X-Received: by 10.182.131.196 with SMTP id oo4mr4301941obb.50.1383345754871; Fri, 01 Nov 2013 15:42:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.73.42 with HTTP; Fri, 1 Nov 2013 15:42:19 -0700 (PDT) In-Reply-To: References: <5273FA71.4000500@gmx.net> <1D4A7D8A-A532-4368-B0E0-87B73B57F1EC@oracle.com> <52740DAD.9030102@gmx.net> From: Josh Mandel Date: Fri, 1 Nov 2013 18:42:19 -0400 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=001a11c1f6d652258204ea254845 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-hunt-oauth-client-association-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 22:42:36 -0000 --001a11c1f6d652258204ea254845 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Justin, Well, I spent ~20min to read over this pair of drafts (association + software_statement). I have to say that in isolation, I find this approach quite reasonable. In particular: 1. This approach does *not* require both a bearer token and software_statement for the registration step. The software_statement alone should work for a case lke B. (Bearer token is only presented to the registration endpoint for refresh/update -- or if some out of band authz needs to be communicated.) 2. This approach is very friendly for public ("transient") clients. No need to delete/expire/repeat the regsitration. Under this spec, a BB+ Registry would produce software_statements instead of preregistration_jwts, but otherwise works the same. I'm definitely interested to hear what you see as the drawbacks -J ---------- Forwarded message ---------- From: Phil Hunt Date: Fri, Nov 1, 2013 at 6:02 PM Subject: Re: [OAUTH-WG] draft-hunt-oauth-client-association-00 To: Hannes Tschofenig Cc: "oauth@ietf.org WG" I think for the client types, the trick is to try to make it restrictive enough so there's no second-guessing the client developer has to do about what SPs will accept. The line I was drawing was for implicit/javascript clients in the current draft. We could open it to a simple decision for the client developer. If they think they will need an instance specific client_id from service endpoints, then they need to use dynamic registration. Otherwise transient registration could be used for on-the-fly transient associations - which are still public clients. My assessment was we could keep transient restricted to implicit/javascript only - making the choice very clear. But I'd love to hear if someone has a case where they think transient fits a client doing one of the other authorization flows (the broader case). BTW=85.this is why the client association draft is in fact so long. There = is considerable text discussing the classifications and their differences. Looking at it now, I'm starting to feel stricter "normative" text (MUSTs & SHOULDS) and less fuzzy explanation and/or examples might actually be better for inter-op and perceived simplicity/clarity. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-11-01, at 1:23 PM, Hannes Tschofenig wrote: > Hi Phil, > > We definitely have to figure out how the differentiation is made so that > a developer (or someone who deploys the technology) understands the > scenario they are in and what the implications are. At the moment I > would struggle a bit. > > Using examples is certainly a good idea, like you did below. There are, > however, quickly challenges. For example, in the JavaScript case below > you can imagine a developer of a smart phone app who uses JavaScript but > then packages the application (using PhoneGap), which makes it behave > very much like a native app. > > And, as you say below, the notion of whether the endpoint is configured upfront (during development time) or dynamically configured may not necessarily matter. > > It definitely makes sense to discuss this during the meeting and real-world examples may help. > > Ciao > Hannes > > Am 01.11.13 20:56, schrieb Phil Hunt: >> Hannes, >> >> Great timing! >> >> This is an aspect that I think deserves more discussion. One of the >> challenges was to draw a clear line of distinction between transient >> and dynamic. >> >> Transient clients are really meant for javascript clients that decide >> to connect to a particular end-point on the fly. Note you can still >> have "static" javascript clients that are hard coded to connect and >> have already received a client_id through an out-of-band process. >> >> Phil >> >> @independentid www.independentid.com phil.hunt@oracle.com >> >> On 2013-11-01, at 12:01 PM, Hannes Tschofenig >> wrote: >> >>> Hi Phil, Hi Tony, Hi all, >>> >>> I re-read the document and I believe the most important concept it >>> introduces is the classification of different associations, namely >>> into 'static', 'dynamic', and 'transient'. This is certainly >>> something worthwhile to discuss during the meeting and to ensure >>> that it is well understood, and that there are only these three >>> classes (rather than two or four). >>> >>> The description in the introduction makes the differentiation >>> between the three concepts mostly based on how the endpoints are >>> configured in the application. >>> >>> With the static association the endpoint is hard-coded into the >>> software during the development time. It cannot be changed. With >>> the two other cases the endpoint can be changed. As such, the >>> difference between the 'dynamic', and 'transient' association seems >>> to be in the terms of how long the lifetime of the association. >>> Now, what exactly is the lifetime of an association? Is the >>> lifetime of the association understood as the lifetime of the >>> configured endpoint identifier? >>> >>> Then, when I re-read the text in Section 1 again then I suddenly >>> get the impression that the lifetime of the association actually >>> does not matter but instead the difference is rather whether the >>> client is public or confidential. Is that true? >>> >>> If it isn't true that this is the feature that makes the >>> distinction between 'dynamic', and 'transient' then the notion of >>> "public" vs. "confidential" client isn't too important for the rest >>> of the document. >>> >>> Ciao Hannes >>> >>> >>> _______________________________________________ OAuth mailing list >>> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --001a11c1f6d652258204ea254845 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Justin,

Well, I spent ~20min to read= over this pair of drafts (association + software_statement). I have to say= that in isolation, I find this approach quite reasonable. In particular:
1. This approach does *not* require both a bearer token and softwa= re_statement for the registration step. The software_statement alone should= work for a case lke B. (Bearer token is only presented to the registration= endpoint for refresh/update -- or if some out of band authz needs to be co= mmunicated.)

2. This approach is very friendly for public ("transient") cl= ients. =A0No need to delete/expire/repeat the regsitration.

<= /div>
Under this spec, a BB+ Registry would produce software_statements= instead of preregistration_jwts, but otherwise works the same.

I'm definitely interested to hear what you see as t= he drawbacks

=A0 -J

---------- Forwarded message ----------
From: Phil Hunt <phil.hunt@oracle.com>
Date: Fri, Nov 1, 2013 at 6:02 PM
Subject: Re: [OAUTH-WG] draft-hunt-oau= th-client-association-00
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Cc: "oauth@ietf.org WG" <oauth@ietf.org>


I think for the client types, the trick is to try to make it restri= ctive enough so there's no second-guessing the client developer has to = do about what SPs will accept. =A0The line I was drawing was for implicit/j= avascript clients in the current draft.

We could open it to a simple decision for the client developer. =A0If they = think they will need an instance specific client_id from service endpoints,= then they need to use dynamic registration. =A0Otherwise transient registr= ation could be used for on-the-fly transient associations - which are still= public clients.

My assessment was we could keep transient restricted to implicit/javascript= only - making the choice very clear. =A0But I'd love to hear if someon= e has a case where they think transient fits a client doing one of the othe= r authorization flows (the broader case).

BTW=85.this is why the client association draft is in fact so long. =A0Ther= e is considerable text discussing the classifications and their differences= .

Looking at it now, I'm starting to feel stricter "normative" = text (MUSTs & SHOULDS) and less fuzzy explanation and/or examples might= actually be better for inter-op and perceived simplicity/clarity.

Phil

@independentid
www.independenti= d.com
phil.hunt@oracle.com

On 2013-11-01, at 1:23 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

> Hi Phil,
>
> We definitely have to figure out how the differentiation is made so th= at
> a developer (or someone who deploys the technology) understands the > scenario they are in and what the implications are. At the moment I > would struggle a bit.
>
> Using examples is certainly a good idea, like you did below. There are= ,
> however, quickly challenges. For example, in the JavaScript case below=
> you can imagine a developer of a smart phone app who uses JavaScript b= ut
> then packages the application (using PhoneGap), which makes it behave<= br> > very much like a native app.
>
> And, as you say below, the notion of whether the endpoint is configure= d upfront (during development time) or dynamically configured may not neces= sarily matter.
>
> It definitely makes sense to discuss this during the meeting and real-= world examples may help.
>
> Ciao
> Hannes
>
> Am 01.11.13 20:56, schrieb Phil Hunt:
>> Hannes,
>>
>> Great timing!
>>
>> This is an aspect that I think deserves more discussion. One of th= e
>> challenges was to draw a clear line of distinction between transie= nt
>> and dynamic.
>>
>> Transient clients are really meant for javascript clients that dec= ide
>> to connect to a particular end-point on the fly. =A0Note you can s= till
>> have "static" javascript clients that are hard coded to = connect and
>> have already received a client_id through an out-of-band process.<= br> >>
>> Phil
>>
>> @independentid www.independentid.com p= hil.hunt@oracle.com
>>
>> On 2013-11-01, at 12:01 PM, Hannes Tschofenig
>> <hannes.tschofenig= @gmx.net> wrote:
>>
>>> Hi Phil, Hi Tony, Hi all,
>>>
>>> I re-read the document and I believe the most important concep= t it
>>> introduces is the classification of different associations, na= mely
>>> into 'static', 'dynamic', and 'transient&#= 39;. This is certainly
>>> something worthwhile to discuss during the meeting and to ensu= re
>>> that it is well understood, and that there are only these thre= e
>>> classes (rather than two or four).
>>>
>>> The description in the introduction makes the differentiation<= br> >>> between the three concepts mostly based on how the endpoints a= re
>>> configured in the application.
>>>
>>> With the static association the endpoint is hard-coded into th= e
>>> software during the development time. It cannot be changed. Wi= th
>>> the two other cases the endpoint can be changed. As such, the<= br> >>> difference between the 'dynamic', and 'transient&#= 39; association seems
>>> to be in the terms of how long the lifetime of the association= .
>>> Now, what exactly is the lifetime of an association? Is the >>> lifetime of the association understood as the lifetime of the<= br> >>> configured endpoint identifier?
>>>
>>> Then, when I re-read the text in Section 1 again then I sudden= ly
>>> get the impression that the lifetime of the association actual= ly
>>> does not matter but instead the difference is rather whether t= he
>>> client is public or confidential. Is that true?
>>>
>>> If it isn't true that this is the feature that makes the >>> distinction between 'dynamic', and 'transient'= then the notion of
>>> "public" vs. "confidential" client isn'= ;t too important for the rest
>>> of the document.
>>>
>>> Ciao Hannes
>>>
>>>
>>> _______________________________________________ OAuth mailing = list
>>> OAuth@ietf.org https://= www.ietf.org/mailman/listinfo/oauth
>>
>

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--001a11c1f6d652258204ea254845-- From sakimura@gmail.com Sat Nov 2 01:31:54 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F04111E814B for ; Sat, 2 Nov 2013 01:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2t+nSL2TarPh for ; Sat, 2 Nov 2013 01:31:53 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 67F3711E80EC for ; Sat, 2 Nov 2013 01:31:52 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id eo20so655862lab.9 for ; Sat, 02 Nov 2013 01:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UzjOH/aDBH5KO/iflf2fPYBuBiIVHkpZl2r5uwosjhE=; b=C+igVKa0eZLvFSodohz49serAzZv/x9QmblEs2NE/gS4jRnyDESnqdzwMXhsZDt6bw DisJN7o/nm8a4KA0g4Cs/Ld3clgPBIpHHtxNccugg8o+WqJ/rJgze1GcW+ogcave6ffm o3g7QgiLLVKtSHdu44wiBoTAkw7VHCMMh1Jlv4DhIgdDrn+kig+0ig1embiDTfLUhJJj HUYs91WnAzQhZNF79/aUhyK+6hIZxRImaS11cZxx8wr6GzjzvCJ9SlIAELP0pl/xMROK wnWih/0a16LV6aVHhcIR/PfnWytnZA6IyYfibk8eejS3GtBPH+IPmXp87OJDL57LLijy ZDvw== MIME-Version: 1.0 X-Received: by 10.112.29.147 with SMTP id k19mr4083603lbh.9.1383381111259; Sat, 02 Nov 2013 01:31:51 -0700 (PDT) Received: by 10.112.134.38 with HTTP; Sat, 2 Nov 2013 01:31:51 -0700 (PDT) In-Reply-To: <7837710edb6a43e0bb098435dd1c9f51@BLUPR03MB184.namprd03.prod.outlook.com> References: <7837710edb6a43e0bb098435dd1c9f51@BLUPR03MB184.namprd03.prod.outlook.com> Date: Sat, 2 Nov 2013 17:31:51 +0900 Message-ID: From: Nat Sakimura To: Anthony Nadalin Content-Type: multipart/alternative; boundary=001a1133aa86b9c84104ea2d830c Cc: Derek Atkins , "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Agenda for IETF-88 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 08:31:54 -0000 --001a1133aa86b9c84104ea2d830c Content-Type: text/plain; charset=ISO-8859-1 Could you send me an I-D or blog post etc. for ActAs? Over a year ago, I posted this: http://nat.sakimura.org/2012/08/03/named-token/ and it may be closely related. 2013/11/1 Anthony Nadalin > Would like 10 min to discuss ActAs draft > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Derek Atkins > Sent: Thursday, October 31, 2013 1:07 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] OAuth Agenda for IETF-88 > > The IETF is next week, and OAuth meets Monday Afternoon. We have a 2-1/2 > hour session, and I expect we'll use most of it for discussion. For anyone > who wants to make a status update on their draft please: > > 1) Get me slides before the meeting so I can post them online, > 2) Try to keep yourself to a MAX of THREE (3) slides > 3) Try to keep your comments to under 10 minutes (under 5 even better) > > Face to face time is best used for discussion, not presentation. :) > > Here is the proposed agenda. I'll post this on the website before the > meeting on Monday. Please let me know if you have any additions before > then. > > > * Welcome & Agenda Bashing (10 minutes) > * Draft Statuses (20 minutes) > * Discussion (2 hours) > - draft-bradley-stateless-oauth-client (30 min max) > - Proof of Possession (30 min max) > - Dynamic Client Registration (remainder, 60+min) > * draft-richer-oauth-dyn-reg-core > * draft-richer-oauth-dyn-reg-management > * ... > > > -derek > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a1133aa86b9c84104ea2d830c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Could you send me an I-D or blog post etc. for ActAs?=A0
Over a year ago, I posted this:=A0http://nat.sakimura.org/2012/08/03/nam= ed-token/=A0and it may be closely related.=A0


2013/11= /1 Anthony Nadalin <tonynad@microsoft.com>
Would like 10 min to discuss ActAs draft

-----Original Message-----
From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of Derek Atkins
Sent: Thursday, October 31, 2013 1:07 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] OAuth Agenda for IETF-88

The IETF is next week, and OA= uth meets Monday Afternoon. =A0We have a 2-1/2 hour session, and I expect w= e'll use most of it for discussion. =A0For anyone who wants to make a s= tatus update on their draft please:

1) Get me slides before the meeting so I can post them online,
2) Try to keep yourself to a MAX of THREE (3) slides
3) Try to keep your comments to under 10 minutes (under 5 even better)

Face to face time is best used for discussion, not presentation. =A0:)

Here is the proposed agenda. =A0I'll post this on the website before th= e meeting on Monday. =A0Please let me know if you have any additions before= then.


* Welcome & Agenda Bashing (10 minutes)
* Draft Statuses (20 minutes)
* Discussion (2 hours)
=A0 - draft-bradley-stateless-oauth-client (30 min max)
=A0 - Proof of Possession (30 min max)
=A0 - Dynamic Client Registration (remainder, 60+min)
=A0 =A0 * draft-richer-oauth-dyn-reg-core
=A0 =A0 * draft-richer-oauth-dyn-reg-management
=A0 =A0 * ...


-derek

--
=A0 =A0 =A0 =A0Derek Atkins =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 617-623-3745 =A0 =A0 =A0 =A0derek@ihtfp.com =A0 = =A0 =A0 =A0 =A0 =A0 www.= ihtfp.com
=A0 =A0 =A0 =A0Computer and Internet Security Consultant

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en
--001a1133aa86b9c84104ea2d830c-- From hannes.tschofenig@gmx.net Sat Nov 2 02:07:51 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2DE11E8128 for ; Sat, 2 Nov 2013 02:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TYdX1YE5dK2 for ; Sat, 2 Nov 2013 02:07:45 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 179F411E80EC for ; Sat, 2 Nov 2013 02:07:42 -0700 (PDT) Received: from masham-mac.home ([81.164.176.169]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lomql-1WAFQf1Atf-00glGc for ; Sat, 02 Nov 2013 10:07:38 +0100 Message-ID: <5274C0D9.9070300@gmx.net> Date: Sat, 02 Nov 2013 10:07:37 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "oauth@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:SXahbtcWy2z0M75KOzCKz6lWEL1S+WumH5ZOY25ratYvji9WyAE sBbAB/YbOEzO5u9YK1wdxNVFfsvBZKgk3jnWxKmoykviW3Q4Y2AlWQAypcvP2zim+Fc4Q9k uMcXYaQoJ45UEJy1jcqENFmmiDMDXBKm30JkJ9qQVLE9HuVfxemICeaee31LSb6VBsAHmFq aphKHo8JED64zJ5QUF5Gw== Subject: [OAUTH-WG] draft-ietf-oauth-saml2-bearer-17 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 09:07:51 -0000 Hi Brian, Hi all, I read through the SAML Bearer draft and here are a few comments: (actually some of the comments that I made yesterday regarding draft-ietf-oauth-jwt-bearer-06) Section 3: Item #1: You wrote: "Issuer values SHOULD be compared using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986 [RFC3986], unless otherwise specified by the application." I would put a MUST here. You can also use the text I proposed for draft-ietf-oauth-jwt-bearer-06, which is text I copied from the TLS specification. Also the comment regarding the comparison operation I made in draft-ietf-oauth-jwt-bearer-06 is applicable here. Item #2: You wrote: " Section 2.5.1.4 of Assertions and Protocols for the OASIS Security Assertion Markup Language [OASIS.saml-core-2.0-os] defines the and elements and, in addition to the URI references discussed there, the token endpoint URL of the authorization server MAY be used as a URI that identifies the authorization server as an intended audience. Assertions that do not identify the Authorization Server as an intended audience MUST be rejected. " The 'MAY' is extremely weak here. If you make it a MUST that there has to be the endpoint URL of the authorization server in there then that would provide so much more interoperability. As a reader I wouldn't know what other options I have and systems that provision necessary databases / tables to ensure that the comparison takes place will also struggle. Then, there is again this SHOULD regarding the comparison operation, see " Audience values SHOULD be compared using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986 [RFC3986], unless otherwise specified by the application. " I would replace it with a MUST, as I argued in draft-ietf-oauth-jwt-bearer-06. Item #3: As in the draft-ietf-oauth-jwt-bearer-06 this part is extremely fluffy, except for the case where it talks about the client-id. What exactly do I put into the field in the case of an authorization grant? Item #5: You write: " The element MUST contain at least one element that allows the authorization server to confirm it as a Bearer Assertion. " What do you mean that the AS confirms that it is a bearer assertion? I think what you rather want to say is that the AS indicates that it is a bearer assertion. Item #7+8: T I think you should combine the two items since they relate to the same issue, namely when to include the element. There are two questions: Q1: Has the subject been authenticated? If 'no', then the cannot be populated. If 'yes', then Q2: Has the subject requested to be anonymous? If 'no', then the element is populated with the subject's identity. If 'yes', then the MUST NOT be populated. (or populated with a field that indicates that the subject is anonymous; I don't know SAML enough to tell what the right approach here is). Then you write: " The presenter SHOULD be identified in the or similar element in the element, or by other available means like SAML V2.0 Condition for Delegation Restriction [OASIS.saml-deleg-cs]. " Who is the presenter? Is the presenter the subject? Item #10: You write: " 10. The Assertion MUST be digitally signed or have a keyed message digest applied by the issuer. The authorization server MUST reject assertions with an invalid signature or keyed message digest. " To my knowledge SAML assertions only support digitial signatures and no keyed message digests. Security Consideration section: I believe the section needs to say two things into addition to the reference to the other specifications, which are already included in the security consideration section: a) The specification does not mandate replay protection for the SAML assertion usage for neither the authorization grant nor for the client authentication. It is an optional feature. b) There is actually no authentication happening when these SAML assertions are used for client authentication and for the authorization grant (in the classical definition of authentication). This may be surprising to some why typically assume that the client would have to demonstrate proof of possession of a secret, which isn't the case here. It would have been possible to provide more enhanced funtionality (and SAML supports this as well) but it is not provided in the specification. Maybe a future specification will provide that functionalility. I think it is worth pointing out. Ciao Hannes From hannes.tschofenig@gmx.net Sat Nov 2 03:22:15 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4F811E81C6 for ; Sat, 2 Nov 2013 03:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ejzKaOBkMgg for ; Sat, 2 Nov 2013 03:22:09 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 98BD311E8186 for ; Sat, 2 Nov 2013 03:21:46 -0700 (PDT) Received: from masham-mac.home ([81.164.176.169]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MhNk6-1VH14d0rpa-00MZvD for ; Sat, 02 Nov 2013 11:21:45 +0100 Message-ID: <5274D238.8070803@gmx.net> Date: Sat, 02 Nov 2013 11:21:44 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "oauth@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:pSNrfZdRfNvXoLVlsL6AG8P3EhK1V1mOYhJ0GYfOjG9yo30ZaVJ /YipArn6k9D+zLjdmxzniNYdaL9xJ0ejKV2nLmr+W+o8iSHE6TLRnSEZ2xc5Mi5IFjd8cpp AiVEjg31Wtd3Ke4ckzkWSylyq77NtYucOCDCYcM4+CiRNpEz/yH36fY1QQjyAmpJqEIhy4q nVkee9G4ZDZ2Q/7fDKNsQ== Subject: [OAUTH-WG] Dynamic Client Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 10:22:15 -0000 Hi all, reading througth various dynamic client registration document I get the impression that there is one area of potential disconnect, namely in the end user / developer experience. When OpenID started this concept that a random IdP could talk to a random RP it seemed like a great idea. There was no need to exchange secrets and go through this complicated introduction process between the different parties, which sometimes even required business argeements. Those processes were known from Kerberos and also from the SAML identity federations. OpenID looked at the entire step from a technical point of view in an attempt to exchange the necessary information and then you were done with it. However, there was a bit more to this whole process, namely the entire notion of trust. In particular, there was the problem that the IdP would hand out information (personal data) to RPs only based on the user's consent. Of course, things could go wrong and some RPs misused the data given by the RP. The IdP couldn't really do anything about that since it knew nothing about the developer at the RP or the RP itself. So, how does the IdP ensure that it has some way to improve security and privacy of their users without handing out just everything. Of course, the IdP had it's own interest to know to know data is being passed to. Jumping to OAuth many deployments required developers to register and this registration procedure might require lots of information (such as credit card number, phone number, agreeing the terms of service, etc.). So, in many cases it wasn't purely about giving the developer a client-id and a shared secret for the client application. Now, here is the challenge: there are obviously different environments developers produce software for (such as the Web, the mobile app eco-system, and enterprise environments). They might all have different processes and expectations about the entire process. We have pretty much short-cut the entire story to the purely technical parts, namely to sending messages around and defining new attributes and have done very little in describing the process itself that we assume takes place. I know that you have these processes in your head when you write your documents and in discussions I have heard about these processes. Unfortunately, they aren't really documented anywhere. I guess it is needless to say that the expectations about how enterprises plan to deploy software vs. how the same is done for the Web is somewhat different. So, I believe it is useful to chat about these aspects even though they may just lead to a few paragraphs in our documents providing background information rather than actual normative specification text. Ciao Hannes From phil.hunt@oracle.com Sat Nov 2 09:08:57 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A9521E8098 for ; Sat, 2 Nov 2013 09:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.305 X-Spam-Level: X-Spam-Status: No, score=-6.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZgbLK2UmR-h for ; Sat, 2 Nov 2013 09:08:52 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7B81111E815F for ; Sat, 2 Nov 2013 09:08:48 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA2G8drO030093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 2 Nov 2013 16:08:40 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA2G8cOU016155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Nov 2013 16:08:39 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA2G8cmE016146; Sat, 2 Nov 2013 16:08:38 GMT Received: from [192.168.1.12] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 02 Nov 2013 09:08:38 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <5274D238.8070803@gmx.net> Date: Sat, 2 Nov 2013 09:08:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <49AA7409-C574-43E4-8D44-827092B356B2@oracle.com> References: <5274D238.8070803@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1510) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Dynamic Client Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 16:08:57 -0000 Hannes, Some really good, thought provoking comments! I had not really been = focused as much on financial relationships between SP and client. I must = confess I considered web clients that set up major relations with = service providers. In these cases I dismissed them as a use case because = they would most likely configure manually and actually end up in the = "static" class of clients. Still, I think we should give this some more = careful thought. What were you thinking of as a "enterprise" that differentiates with = what we are currently talking about? Enterprise these days has so much = derogatory baggage that it is hard to tell what is being referred to. There is a quality of APIs that 6749 focuses on that registration can = fix. 6749 works well for "monopoly"/"singleton" API providers like = Google, Facebook, etc. Yet there are lots of "open" APIs established = through open source projects, open standards (e.g. Connect), and = commercial cases where customers will deploy their own copies of an API. = I'm not sure this really is "enterprise". Even in the commercial = cases, these APIs are most often made available as "open" for use by = third party developers. For me, this isn't a case of extending OAuth to = support "enterprise", but rather extending OAuth to support "open" or = "multiple-deployment" APIs on the web no matter where or how they are = deployed. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-11-02, at 3:21 AM, Hannes Tschofenig = wrote: > Hi all, >=20 > reading througth various dynamic client registration document I get = the impression that there is one area of potential disconnect, namely in = the end user / developer experience. >=20 > When OpenID started this concept that a random IdP could talk to a = random RP it seemed like a great idea. There was no need to exchange = secrets and go through this complicated introduction process between the = different parties, which sometimes even required business argeements. = Those processes were known from Kerberos and also from the SAML identity = federations. >=20 > OpenID looked at the entire step from a technical point of view in an = attempt to exchange the necessary information and then you were done = with it. >=20 > However, there was a bit more to this whole process, namely the entire = notion of trust. In particular, there was the problem that the IdP would = hand out information (personal data) to RPs only based on the user's = consent. Of course, things could go wrong and some RPs misused the data = given by the RP. The IdP couldn't really do anything about that since it = knew nothing about the developer at the RP or the RP itself. >=20 > So, how does the IdP ensure that it has some way to improve security = and privacy of their users without handing out just everything. Of = course, the IdP had it's own interest to know to know data is being = passed to. >=20 > Jumping to OAuth many deployments required developers to register and = this registration procedure might require lots of information (such as = credit card number, phone number, agreeing the terms of service, etc.). = So, in many cases it wasn't purely about giving the developer a = client-id and a shared secret for the client application. >=20 > Now, here is the challenge: there are obviously different environments = developers produce software for (such as the Web, the mobile app = eco-system, and enterprise environments). They might all have different = processes and expectations about the entire process. >=20 > We have pretty much short-cut the entire story to the purely technical = parts, namely to sending messages around and defining new attributes and = have done very little in describing the process itself that we assume = takes place. >=20 > I know that you have these processes in your head when you write your = documents and in discussions I have heard about these processes. = Unfortunately, they aren't really documented anywhere. I guess it is = needless to say that the expectations about how enterprises plan to = deploy software vs. how the same is done for the Web is somewhat = different. >=20 > So, I believe it is useful to chat about these aspects even though = they may just lead to a few paragraphs in our documents providing = background information rather than actual normative specification text. >=20 > Ciao > Hannes > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Sat Nov 2 21:28:43 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A07C11E818D for ; Sat, 2 Nov 2013 21:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.383 X-Spam-Level: X-Spam-Status: No, score=-6.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7foR2TMGfy9X for ; Sat, 2 Nov 2013 21:28:38 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEE911E8171 for ; Sat, 2 Nov 2013 21:28:38 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EFEC11F02D0; Sun, 3 Nov 2013 00:28:37 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id DD2201F027F; Sun, 3 Nov 2013 00:28:37 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.251]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0158.001; Sun, 3 Nov 2013 00:28:37 -0400 From: "Richer, Justin P." To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] Dynamic Client Registration Thread-Index: AQHO17VpgVm3wOfIFkiR4ENfx3W3lpoTPrkA Date: Sun, 3 Nov 2013 04:28:36 +0000 Message-ID: <2799AEE6-F443-4591-A3C4-D20258A81AE0@mitre.org> References: <5274D238.8070803@gmx.net> In-Reply-To: <5274D238.8070803@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.39.41] Content-Type: text/plain; charset="us-ascii" Content-ID: <30FEAEAAA056854AB328A43CA227E36D@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Dynamic Client Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 04:28:43 -0000 Hannes, There are a number of major use cases and expectations that I've kept in mi= nd throughout the development of this protocol. Some of the fallout of this= is captured in appendix B of the current draft, but I'd be happy to write = them out here: First, the use cases of OpenID Connect and UMA are driving factors, which s= houldn't be surprising since the draft that we have now came into existence= by combining the UMA dynamic registration draft (which started its life ov= er 3 years ago now) and the OpenID Connect dynamic registration draft (whic= h is at least 2 years old). In both of these cases, the trust starts at the= end user, who effectively makes the introductions between the different co= mponents. For example, in Connect's fully open and distributed mode, the en= d user types in a web finger address at the RP to point to an IdP that the = RP's potentially never heard of. That RP needs to be able to talk to that I= dP in real time, while the user is still there. Likewise in UMA, the end us= er points the client at the API which discovers the AS. Any kind of step th= at requires a system administrator or developer to be involved is a dead st= op for the fully distributed cases of these protocols, since the whole poin= t is to *automate* the process of registration. The case is even more clear= with BlueButton+, a healthcare data access protocol, where the end user is= the patient. The patient has the right and ability to connect their health= care provider's API (protected by the provider's AS) to a client of the pa= tient's choosing, even if the provider or the provider's software vendor ha= s never heard of the client software before.=20 That said, there's a "more trusted" middle ground where you get authorized = to call the registration endpoint, and you can show that by presenting an i= nitial access token as part of that request. We've taken that mechanism wit= h BlueButton+ and defined our own initial access token as a signed JWT asse= rtion presented as a bearer assertion. (There's also a discovery protocol i= n BB+ that defines how the AS can validate the assertion.) Large providers,= like the Googles and Facebooks of the world, like to have a relationship w= ith the developer ahead of time. The developer is effectively issued an acc= ess token to tie their clients back to the developer's account. There can b= e a problem with this though, and it's important to think of the dynamic re= gistration from two perspectives:=20 >From the perspective of the AS, the protocol is all about introducing new c= lients. In this view, you've got an AS with lots of different client applic= ations trying to talk to it. These might be many copies of the same code ba= se, or many different code bases, but each instance needs to be able to pre= sent a client_id and client_secret (or equivalent authentication) that the = AS can recognize. In an enterprise, it's common to think from this perspect= ive because it's usually the enterprise that's rolling out the AS and wanti= ng to provide access to a published API to a bunch of clients that may or m= ay not be known ahead of time.=20 >From the perspective of the client (which is really to say, an instance of = a client), the protocol is all about introducing the client to a bunch of d= ifferent auth servers. This is usually the case when you've got an "open" A= PI, like OIDC, that may be hosted by any number of unknown parties that nee= d to be discovered at runtime. One client can talk to a number of different= instantiations of this same API. This perspective often gets lost when peo= ple talk about deploying auth servers (especially the large internet provid= ers) or having some kind of trusted registration, like what Google wants to= do with giving developers access tokens. However, I think that this perspe= ctive is going to become more important as we have more widespread common A= PIs and better service discovery systems. Note that in BB+ we have both op= en and trusted registrations, with the open registrations MTI. Extensibility of the base draft is also a very important consideration to m= e. OAuth works because it's a set of composable blocks that can be brought = together to solve a wide variety of problems. As such, it's important that = the client's metadata be safely and easily extensible so that specific prot= ocols being protected by OAuth (like Connect or Blue Button) can easily def= ine protocol-specific client aspects. This would also be the logical place = to inject Phil's proposed software statement, as an extension to the client= 's presented metadata and a means for protecting particular fields with a s= ignature. Additionally, since OAuth has many different methods of clients a= uthenticating, the draft defines a registry to allow for specific OAuth-pro= tected protocols and systems to define different auth methods, like Connect= 's private_key_jwt and client_secret_jwt methods that are more specific to = how Connect defines its interactions. I'm sure there will be other methods = in the future, too. Finally, the ability of the client to manage the metadata that's attached t= o a client_id over time is important in some use cases. Fundamentally, the = registration process is the "Create" verb, and the "Read/Update/Delete" ver= bs are a short step after that to implement. It's become clear to me that i= f your authorization servers are fully stateless, or if you believe that al= l of the metadata properties of a given client (or even piece of software w= ith multiple instances), then the management API doesn't make any sense. Ho= wever, neither of these assumptions are universal, and with the right compo= nents, we can have a system that can be composed in different ways to fit a= ll of these use cases. -- Justin On Nov 2, 2013, at 6:21 AM, Hannes Tschofenig wrote: > Hi all, >=20 > reading througth various dynamic client registration document I get the i= mpression that there is one area of potential disconnect, namely in the end= user / developer experience. >=20 > When OpenID started this concept that a random IdP could talk to a random= RP it seemed like a great idea. There was no need to exchange secrets and = go through this complicated introduction process between the different part= ies, which sometimes even required business argeements. Those processes wer= e known from Kerberos and also from the SAML identity federations. >=20 > OpenID looked at the entire step from a technical point of view in an att= empt to exchange the necessary information and then you were done with it. >=20 > However, there was a bit more to this whole process, namely the entire no= tion of trust. In particular, there was the problem that the IdP would hand= out information (personal data) to RPs only based on the user's consent. O= f course, things could go wrong and some RPs misused the data given by the = RP. The IdP couldn't really do anything about that since it knew nothing ab= out the developer at the RP or the RP itself. >=20 > So, how does the IdP ensure that it has some way to improve security and = privacy of their users without handing out just everything. Of course, the = IdP had it's own interest to know to know data is being passed to. >=20 > Jumping to OAuth many deployments required developers to register and thi= s registration procedure might require lots of information (such as credit = card number, phone number, agreeing the terms of service, etc.). So, in man= y cases it wasn't purely about giving the developer a client-id and a share= d secret for the client application. >=20 > Now, here is the challenge: there are obviously different environments de= velopers produce software for (such as the Web, the mobile app eco-system, = and enterprise environments). They might all have different processes and e= xpectations about the entire process. >=20 > We have pretty much short-cut the entire story to the purely technical pa= rts, namely to sending messages around and defining new attributes and have= done very little in describing the process itself that we assume takes pla= ce. >=20 > I know that you have these processes in your head when you write your doc= uments and in discussions I have heard about these processes. Unfortunately= , they aren't really documented anywhere. I guess it is needless to say tha= t the expectations about how enterprises plan to deploy software vs. how th= e same is done for the Web is somewhat different. >=20 > So, I believe it is useful to chat about these aspects even though they m= ay just lead to a few paragraphs in our documents providing background info= rmation rather than actual normative specification text. >=20 > Ciao > Hannes > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Sat Nov 2 21:41:59 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DE011E8299 for ; Sat, 2 Nov 2013 21:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.404 X-Spam-Level: X-Spam-Status: No, score=-6.404 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiUtPQuepam5 for ; Sat, 2 Nov 2013 21:41:55 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5703B11E8282 for ; Sat, 2 Nov 2013 21:41:53 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C340C1F02D0; Sun, 3 Nov 2013 00:41:52 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id AF6821F027F; Sun, 3 Nov 2013 00:41:52 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.251]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0158.001; Sun, 3 Nov 2013 00:41:52 -0400 From: "Richer, Justin P." To: Josh Mandel Thread-Topic: [OAUTH-WG] draft-hunt-oauth-client-association-00 Thread-Index: AQHO1zT7cptHlNASpES/9Qoij1BuYZoRDXeAgAAHiYCAABu3gIAACyuAgAIHjIA= Date: Sun, 3 Nov 2013 04:41:51 +0000 Message-ID: <26C9D99A-6CC6-44D0-A977-CA67B97915AF@mitre.org> References: <5273FA71.4000500@gmx.net> <1D4A7D8A-A532-4368-B0E0-87B73B57F1EC@oracle.com> <52740DAD.9030102@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.39.41] Content-Type: multipart/alternative; boundary="_000_26C9D99A6CC644D0A977CA67B97915AFmitreorg_" MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-hunt-oauth-client-association-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 04:41:59 -0000 --_000_26C9D99A6CC644D0A977CA67B97915AFmitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The software statement does make sense and we could use it in BB+ to take t= he place of the registration_jwt, even though I'm not really in favor of in= venting yet another mechanism for presenting an assertion to an OAuth-prote= cted endpoint. The association draft is in many ways semantically equivalent to the existi= ng dynamic registration draft, but less flexible and it overloads the token= endpoint. -- Justin On Nov 1, 2013, at 6:42 PM, Josh Mandel > wrote: Hi Justin, Well, I spent ~20min to read over this pair of drafts (association + softwa= re_statement). I have to say that in isolation, I find this approach quite = reasonable. In particular: 1. This approach does *not* require both a bearer token and software_statem= ent for the registration step. The software_statement alone should work for= a case lke B. (Bearer token is only presented to the registration endpoint= for refresh/update -- or if some out of band authz needs to be communicate= d.) 2. This approach is very friendly for public ("transient") clients. No nee= d to delete/expire/repeat the regsitration. Under this spec, a BB+ Registry would produce software_statements instead o= f preregistration_jwts, but otherwise works the same. I'm definitely interested to hear what you see as the drawbacks -J ---------- Forwarded message ---------- From: Phil Hunt > Date: Fri, Nov 1, 2013 at 6:02 PM Subject: Re: [OAUTH-WG] draft-hunt-oauth-client-association-00 To: Hannes Tschofenig > Cc: "oauth@ietf.org WG" > I think for the client types, the trick is to try to make it restrictive en= ough so there's no second-guessing the client developer has to do about wha= t SPs will accept. The line I was drawing was for implicit/javascript clie= nts in the current draft. We could open it to a simple decision for the client developer. If they th= ink they will need an instance specific client_id from service endpoints, t= hen they need to use dynamic registration. Otherwise transient registratio= n could be used for on-the-fly transient associations - which are still pub= lic clients. My assessment was we could keep transient restricted to implicit/javascript= only - making the choice very clear. But I'd love to hear if someone has = a case where they think transient fits a client doing one of the other auth= orization flows (the broader case). BTW=85.this is why the client association draft is in fact so long. There = is considerable text discussing the classifications and their differences. Looking at it now, I'm starting to feel stricter "normative" text (MUSTs & = SHOULDS) and less fuzzy explanation and/or examples might actually be bette= r for inter-op and perceived simplicity/clarity. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-11-01, at 1:23 PM, Hannes Tschofenig > wrote: > Hi Phil, > > We definitely have to figure out how the differentiation is made so that > a developer (or someone who deploys the technology) understands the > scenario they are in and what the implications are. At the moment I > would struggle a bit. > > Using examples is certainly a good idea, like you did below. There are, > however, quickly challenges. For example, in the JavaScript case below > you can imagine a developer of a smart phone app who uses JavaScript but > then packages the application (using PhoneGap), which makes it behave > very much like a native app. > > And, as you say below, the notion of whether the endpoint is configured u= pfront (during development time) or dynamically configured may not necessar= ily matter. > > It definitely makes sense to discuss this during the meeting and real-wor= ld examples may help. > > Ciao > Hannes > > Am 01.11.13 20:56, schrieb Phil Hunt: >> Hannes, >> >> Great timing! >> >> This is an aspect that I think deserves more discussion. One of the >> challenges was to draw a clear line of distinction between transient >> and dynamic. >> >> Transient clients are really meant for javascript clients that decide >> to connect to a particular end-point on the fly. Note you can still >> have "static" javascript clients that are hard coded to connect and >> have already received a client_id through an out-of-band process. >> >> Phil >> >> @independentid www.independentid.com phil= .hunt@oracle.com >> >> On 2013-11-01, at 12:01 PM, Hannes Tschofenig >> > wrote: >> >>> Hi Phil, Hi Tony, Hi all, >>> >>> I re-read the document and I believe the most important concept it >>> introduces is the classification of different associations, namely >>> into 'static', 'dynamic', and 'transient'. This is certainly >>> something worthwhile to discuss during the meeting and to ensure >>> that it is well understood, and that there are only these three >>> classes (rather than two or four). >>> >>> The description in the introduction makes the differentiation >>> between the three concepts mostly based on how the endpoints are >>> configured in the application. >>> >>> With the static association the endpoint is hard-coded into the >>> software during the development time. It cannot be changed. With >>> the two other cases the endpoint can be changed. As such, the >>> difference between the 'dynamic', and 'transient' association seems >>> to be in the terms of how long the lifetime of the association. >>> Now, what exactly is the lifetime of an association? Is the >>> lifetime of the association understood as the lifetime of the >>> configured endpoint identifier? >>> >>> Then, when I re-read the text in Section 1 again then I suddenly >>> get the impression that the lifetime of the association actually >>> does not matter but instead the difference is rather whether the >>> client is public or confidential. Is that true? >>> >>> If it isn't true that this is the feature that makes the >>> distinction between 'dynamic', and 'transient' then the notion of >>> "public" vs. "confidential" client isn't too important for the rest >>> of the document. >>> >>> Ciao Hannes >>> >>> >>> _______________________________________________ OAuth mailing list >>> OAuth@ietf.org https://www.ietf.org/mailman/list= info/oauth >> > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_26C9D99A6CC644D0A977CA67B97915AFmitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3B8F864E9117FD46A3B2059105860E55@imc.mitre.org> Content-Transfer-Encoding: quoted-printable The software statement does make sense and we could use it in BB+ to ta= ke the place of the registration_jwt, even though I'm not really in favor o= f inventing yet another mechanism for presenting an assertion to an OAuth-p= rotected endpoint. 

The association draft is in many ways semantically equivalent to the e= xisting dynamic registration draft, but less flexible and it overloads the = token endpoint.

 -- Justin

On Nov 1, 2013, at 6:42 PM, Josh Mandel <jmandel@gmail.com>
 wrote:

Hi Justin,

Well, I spent ~20min to read over this pair of drafts (association = 3; software_statement). I have to say that in isolation, I find this approa= ch quite reasonable. In particular:

1. This approach does *not* require both a bearer token and software_s= tatement for the registration step. The software_statement alone should wor= k for a case lke B. (Bearer token is only presented to the registration end= point for refresh/update -- or if some out of band authz needs to be communicated.)

2. This approach is very friendly for public ("transient") client= s.  No need to delete/expire/repeat the regsitration.

Under this spec, a BB+ Registry would produce software_statements = instead of preregistration_jwts, but otherwise works the same.

I'm definitely interested to hear what you see as the drawbacks

  -J

---------- Forwarded message ----------
From: Phil Hunt <phil.hunt@oracle.com> Date: Fri, Nov 1, 2013 at 6:02 PM
Subject: Re: [OAUTH-WG] draft-hunt-oauth-client-association-00
To: Hannes Tschofenig <hann= es.tschofenig@gmx.net>
Cc: "oauth@ietf.org WG" <= ;oauth@ietf.org>


I think for the client types, the trick is to try to make it restrictive en= ough so there's no second-guessing the client developer has to do about wha= t SPs will accept.  The line I was drawing was for implicit/javascript= clients in the current draft.

We could open it to a simple decision for the client developer.  If th= ey think they will need an instance specific client_id from service endpoin= ts, then they need to use dynamic registration.  Otherwise transient r= egistration could be used for on-the-fly transient associations - which are still public clients.

My assessment was we could keep transient restricted to implicit/javascript= only - making the choice very clear.  But I'd love to hear if someone= has a case where they think transient fits a client doing one of the other= authorization flows (the broader case).

BTW=85.this is why the client association draft is in fact so long.  T= here is considerable text discussing the classifications and their differen= ces.

Looking at it now, I'm starting to feel stricter "normative" text= (MUSTs & SHOULDS) and less fuzzy explanation and/or examples might act= ually be better for inter-op and perceived simplicity/clarity.

Phil

@independentid
www.independent= id.com
phil.hunt@oracle.com

On 2013-11-01, at 1:23 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

> Hi Phil,
>
> We definitely have to figure out how the differentiation is made so th= at
> a developer (or someone who deploys the technology) understands the > scenario they are in and what the implications are. At the moment I > would struggle a bit.
>
> Using examples is certainly a good idea, like you did below. There are= ,
> however, quickly challenges. For example, in the JavaScript case below=
> you can imagine a developer of a smart phone app who uses JavaScript b= ut
> then packages the application (using PhoneGap), which makes it behave<= br> > very much like a native app.
>
> And, as you say below, the notion of whether the endpoint is configure= d upfront (during development time) or dynamically configured may not neces= sarily matter.
>
> It definitely makes sense to discuss this during the meeting and real-= world examples may help.
>
> Ciao
> Hannes
>
> Am 01.11.13 20:56, schrieb Phil Hunt:
>> Hannes,
>>
>> Great timing!
>>
>> This is an aspect that I think deserves more discussion. One of th= e
>> challenges was to draw a clear line of distinction between transie= nt
>> and dynamic.
>>
>> Transient clients are really meant for javascript clients that dec= ide
>> to connect to a particular end-point on the fly.  Note you ca= n still
>> have "static" javascript clients that are hard coded to = connect and
>> have already received a client_id through an out-of-band process.<= br> >>
>> Phil
>>
>> @independentid www.independentid.com phil.hunt@oracle.com
>>
>> On 2013-11-01, at 12:01 PM, Hannes Tschofenig
>> <hannes.tschofenig= @gmx.net> wrote:
>>
>>> Hi Phil, Hi Tony, Hi all,
>>>
>>> I re-read the document and I believe the most important concep= t it
>>> introduces is the classification of different associations, na= mely
>>> into 'static', 'dynamic', and 'transient'. This is certainly >>> something worthwhile to discuss during the meeting and to ensu= re
>>> that it is well understood, and that there are only these thre= e
>>> classes (rather than two or four).
>>>
>>> The description in the introduction makes the differentiation<= br> >>> between the three concepts mostly based on how the endpoints a= re
>>> configured in the application.
>>>
>>> With the static association the endpoint is hard-coded into th= e
>>> software during the development time. It cannot be changed. Wi= th
>>> the two other cases the endpoint can be changed. As such, the<= br> >>> difference between the 'dynamic', and 'transient' association = seems
>>> to be in the terms of how long the lifetime of the association= .
>>> Now, what exactly is the lifetime of an association? Is the >>> lifetime of the association understood as the lifetime of the<= br> >>> configured endpoint identifier?
>>>
>>> Then, when I re-read the text in Section 1 again then I sudden= ly
>>> get the impression that the lifetime of the association actual= ly
>>> does not matter but instead the difference is rather whether t= he
>>> client is public or confidential. Is that true?
>>>
>>> If it isn't true that this is the feature that makes the
>>> distinction between 'dynamic', and 'transient' then the notion= of
>>> "public" vs. "confidential" client isn't t= oo important for the rest
>>> of the document.
>>>
>>> Ciao Hannes
>>>
>>>
>>> _______________________________________________ OAuth mailing = list
>>> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
>>
>

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--_000_26C9D99A6CC644D0A977CA67B97915AFmitreorg_-- From phil.hunt@oracle.com Sat Nov 2 22:28:33 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E1021E809D for ; Sat, 2 Nov 2013 22:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.614 X-Spam-Level: X-Spam-Status: No, score=-5.614 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nn2gcWoNsakY for ; Sat, 2 Nov 2013 22:28:28 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 520FC21E8094 for ; Sat, 2 Nov 2013 22:28:28 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA35SPpR032228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 3 Nov 2013 05:28:26 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA35SOdq011962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Nov 2013 05:28:24 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA35SOq8011959; Sun, 3 Nov 2013 05:28:24 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 02 Nov 2013 22:28:23 -0700 References: <5273FA71.4000500@gmx.net> <1D4A7D8A-A532-4368-B0E0-87B73B57F1EC@oracle.com> <52740DAD.9030102@gmx.net> <26C9D99A-6CC6-44D0-A977-CA67B97915AF@mitre.org> Mime-Version: 1.0 (1.0) In-Reply-To: <26C9D99A-6CC6-44D0-A977-CA67B97915AF@mitre.org> Content-Type: multipart/alternative; boundary=Apple-Mail-1AD6E9DB-960D-457F-9D02-205546547A0D Content-Transfer-Encoding: 7bit Message-Id: <55448281-4CB2-4EB3-AD8A-4B50C4EFA3F8@oracle.com> X-Mailer: iPhone Mail (11B511) From: Phil Hunt Date: Sat, 2 Nov 2013 22:28:21 -0700 To: "Richer, Justin P." X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-hunt-oauth-client-association-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 05:28:33 -0000 --Apple-Mail-1AD6E9DB-960D-457F-9D02-205546547A0D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Client assoc is a profile of the existing token endpoint and uses the assert= ion drafts definition of client assertion. As such it is not a new mechanism= .=20 Client assoc is also compatible with assertion draft and thus as new token f= ormats are defined they can automatically be issued via dyn association with= out amending client assoc draft or profiling each time.=20 Phil > On Nov 2, 2013, at 21:41, "Richer, Justin P." wrote: >=20 > The software statement does make sense and we could use it in BB+ to take t= he place of the registration_jwt, even though I'm not really in favor of inv= enting yet another mechanism for presenting an assertion to an OAuth-protect= ed endpoint.=20 >=20 > The association draft is in many ways semantically equivalent to the exist= ing dynamic registration draft, but less flexible and it overloads the token= endpoint. >=20 > -- Justin >=20 > On Nov 1, 2013, at 6:42 PM, Josh Mandel > wrote: >=20 >> Hi Justin, >>=20 >> Well, I spent ~20min to read over this pair of drafts (association + soft= ware_statement). I have to say that in isolation, I find this approach quite= reasonable. In particular: >>=20 >> 1. This approach does *not* require both a bearer token and software_stat= ement for the registration step. The software_statement alone should work fo= r a case lke B. (Bearer token is only presented to the registration endpoint= for refresh/update -- or if some out of band authz needs to be communicated= .) >>=20 >> 2. This approach is very friendly for public ("transient") clients. No n= eed to delete/expire/repeat the regsitration. >>=20 >> Under this spec, a BB+ Registry would produce software_statements instead= of preregistration_jwts, but otherwise works the same. >>=20 >> I'm definitely interested to hear what you see as the drawbacks >>=20 >> -J >>=20 >> ---------- Forwarded message ---------- >> From: Phil Hunt >> Date: Fri, Nov 1, 2013 at 6:02 PM >> Subject: Re: [OAUTH-WG] draft-hunt-oauth-client-association-00 >> To: Hannes Tschofenig >> Cc: "oauth@ietf.org WG" >>=20 >>=20 >> I think for the client types, the trick is to try to make it restrictive e= nough so there's no second-guessing the client developer has to do about wha= t SPs will accept. The line I was drawing was for implicit/javascript clien= ts in the current draft. >>=20 >> We could open it to a simple decision for the client developer. If they t= hink they will need an instance specific client_id from service endpoints, t= hen they need to use dynamic registration. Otherwise transient registration= could be used for on-the-fly transient associations - which are still publi= c clients. >>=20 >> My assessment was we could keep transient restricted to implicit/javascri= pt only - making the choice very clear. But I'd love to hear if someone has= a case where they think transient fits a client doing one of the other auth= orization flows (the broader case). >>=20 >> BTW=E2=80=A6.this is why the client association draft is in fact so long.= There is considerable text discussing the classifications and their differ= ences. >>=20 >> Looking at it now, I'm starting to feel stricter "normative" text (MUSTs &= SHOULDS) and less fuzzy explanation and/or examples might actually be bette= r for inter-op and perceived simplicity/clarity. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >> On 2013-11-01, at 1:23 PM, Hannes Tschofenig w= rote: >>=20 >> > Hi Phil, >> > >> > We definitely have to figure out how the differentiation is made so tha= t >> > a developer (or someone who deploys the technology) understands the >> > scenario they are in and what the implications are. At the moment I >> > would struggle a bit. >> > >> > Using examples is certainly a good idea, like you did below. There are,= >> > however, quickly challenges. For example, in the JavaScript case below >> > you can imagine a developer of a smart phone app who uses JavaScript bu= t >> > then packages the application (using PhoneGap), which makes it behave >> > very much like a native app. >> > >> > And, as you say below, the notion of whether the endpoint is configured= upfront (during development time) or dynamically configured may not necessa= rily matter. >> > >> > It definitely makes sense to discuss this during the meeting and real-w= orld examples may help. >> > >> > Ciao >> > Hannes >> > >> > Am 01.11.13 20:56, schrieb Phil Hunt: >> >> Hannes, >> >> >> >> Great timing! >> >> >> >> This is an aspect that I think deserves more discussion. One of the >> >> challenges was to draw a clear line of distinction between transient >> >> and dynamic. >> >> >> >> Transient clients are really meant for javascript clients that decide >> >> to connect to a particular end-point on the fly. Note you can still >> >> have "static" javascript clients that are hard coded to connect and >> >> have already received a client_id through an out-of-band process. >> >> >> >> Phil >> >> >> >> @independentid www.independentid.com phil.hunt@oracle.com >> >> >> >> On 2013-11-01, at 12:01 PM, Hannes Tschofenig >> >> wrote: >> >> >> >>> Hi Phil, Hi Tony, Hi all, >> >>> >> >>> I re-read the document and I believe the most important concept it >> >>> introduces is the classification of different associations, namely >> >>> into 'static', 'dynamic', and 'transient'. This is certainly >> >>> something worthwhile to discuss during the meeting and to ensure >> >>> that it is well understood, and that there are only these three >> >>> classes (rather than two or four). >> >>> >> >>> The description in the introduction makes the differentiation >> >>> between the three concepts mostly based on how the endpoints are >> >>> configured in the application. >> >>> >> >>> With the static association the endpoint is hard-coded into the >> >>> software during the development time. It cannot be changed. With >> >>> the two other cases the endpoint can be changed. As such, the >> >>> difference between the 'dynamic', and 'transient' association seems >> >>> to be in the terms of how long the lifetime of the association. >> >>> Now, what exactly is the lifetime of an association? Is the >> >>> lifetime of the association understood as the lifetime of the >> >>> configured endpoint identifier? >> >>> >> >>> Then, when I re-read the text in Section 1 again then I suddenly >> >>> get the impression that the lifetime of the association actually >> >>> does not matter but instead the difference is rather whether the >> >>> client is public or confidential. Is that true? >> >>> >> >>> If it isn't true that this is the feature that makes the >> >>> distinction between 'dynamic', and 'transient' then the notion of >> >>> "public" vs. "confidential" client isn't too important for the rest >> >>> of the document. >> >>> >> >>> Ciao Hannes >> >>> >> >>> >> >>> _______________________________________________ OAuth mailing list >> >>> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth >> >> >> > >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-1AD6E9DB-960D-457F-9D02-205546547A0D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Client assoc is a profile of the exist= ing token endpoint and uses the assertion drafts definition of client assert= ion. As such it is not a new mechanism. 

Clien= t assoc is also compatible with assertion draft and thus as new token format= s are defined they can automatically be issued via dyn association without a= mending client assoc draft or profiling each time. 

Phil<= /div>

On Nov 2, 2013, at 21:41, "Richer, Justin P." <jricher@mitre.org> wrote:

The software statement does make sense and we could use it in BB+ to take th= e place of the registration_jwt, even though I'm not really in favor of inve= nting yet another mechanism for presenting an assertion to an OAuth-protecte= d endpoint. 

The association draft is in many ways semantically equivalent to the ex= isting dynamic registration draft, but less flexible and it overloads the to= ken endpoint.

 -- Justin

On Nov 1, 2013, at 6:42 PM, Josh Mandel <jmandel@gmail.com>
 wrote:

Hi Justin,

Well, I spent ~20min to read over this pair of drafts (association + so= ftware_statement). I have to say that in isolation, I find this approach qui= te reasonable. In particular:

1. This approach does *not* require both a bearer token and software_st= atement for the registration step. The software_statement alone should work f= or a case lke B. (Bearer token is only presented to the registration endpoin= t for refresh/update -- or if some out of band authz needs to be communicated.)

2. This approach is very friendly for public ("transient") clients.  No= need to delete/expire/repeat the regsitration.

Under this spec, a BB+ Registry would produce software_statements inste= ad of preregistration_jwts, but otherwise works the same.

I'm definitely interested to hear what you see as the drawbacks

  -J

---------- Forwarded message ----------
From: Phil Hunt <phil.hunt@oracle.com>
Date: Fri, Nov 1, 2013 at 6:02 PM
Subject: Re: [OAUTH-WG] draft-hunt-oauth-client-association-00
To: Hannes Tschofenig <hanne= s.tschofenig@gmx.net>
Cc: "oauth@ietf.org WG" <oauth@ietf.org>


I think for the client types, the trick is to try to make it restrictive eno= ugh so there's no second-guessing the client developer has to do about what S= Ps will accept.  The line I was drawing was for implicit/javascript cli= ents in the current draft.

We could open it to a simple decision for the client developer.  If the= y think they will need an instance specific client_id from service endpoints= , then they need to use dynamic registration.  Otherwise transient regi= stration could be used for on-the-fly transient associations - which are still public clients.

My assessment was we could keep transient restricted to implicit/javascript o= nly - making the choice very clear.  But I'd love to hear if someone ha= s a case where they think transient fits a client doing one of the other aut= horization flows (the broader case).

BTW=E2=80=A6.this is why the client association draft is in fact so long. &n= bsp;There is considerable text discussing the classifications and their diff= erences.

Looking at it now, I'm starting to feel stricter "normative" text (MUSTs &am= p; SHOULDS) and less fuzzy explanation and/or examples might actually be bet= ter for inter-op and perceived simplicity/clarity.

Phil

@independentid
www.independenti= d.com
phil.hunt@oracle.com

On 2013-11-01, at 1:23 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

> Hi Phil,
>
> We definitely have to figure out how the differentiation is made so tha= t
> a developer (or someone who deploys the technology) understands the
= > scenario they are in and what the implications are. At the moment I
= > would struggle a bit.
>
> Using examples is certainly a good idea, like you did below. There are,=
> however, quickly challenges. For example, in the JavaScript case below<= br> > you can imagine a developer of a smart phone app who uses JavaScript bu= t
> then packages the application (using PhoneGap), which makes it behave > very much like a native app.
>
> And, as you say below, the notion of whether the endpoint is configured= upfront (during development time) or dynamically configured may not necessa= rily matter.
>
> It definitely makes sense to discuss this during the meeting and real-w= orld examples may help.
>
> Ciao
> Hannes
>
> Am 01.11.13 20:56, schrieb Phil Hunt:
>> Hannes,
>>
>> Great timing!
>>
>> This is an aspect that I think deserves more discussion. One of the=
>> challenges was to draw a clear line of distinction between transien= t
>> and dynamic.
>>
>> Transient clients are really meant for javascript clients that deci= de
>> to connect to a particular end-point on the fly.  Note you can= still
>> have "static" javascript clients that are hard coded to connect and=
>> have already received a client_id through an out-of-band process. >>
>> Phil
>>
>> @independentid www.independentid.com phil.hunt@oracle.com
>>
>> On 2013-11-01, at 12:01 PM, Hannes Tschofenig
>> <hannes.tschofenig@= gmx.net> wrote:
>>
>>> Hi Phil, Hi Tony, Hi all,
>>>
>>> I re-read the document and I believe the most important concept= it
>>> introduces is the classification of different associations, nam= ely
>>> into 'static', 'dynamic', and 'transient'. This is certainly >>> something worthwhile to discuss during the meeting and to ensur= e
>>> that it is well understood, and that there are only these three=
>>> classes (rather than two or four).
>>>
>>> The description in the introduction makes the differentiation >>> between the three concepts mostly based on how the endpoints ar= e
>>> configured in the application.
>>>
>>> With the static association the endpoint is hard-coded into the=
>>> software during the development time. It cannot be changed. Wit= h
>>> the two other cases the endpoint can be changed. As such, the >>> difference between the 'dynamic', and 'transient' association s= eems
>>> to be in the terms of how long the lifetime of the association.=
>>> Now, what exactly is the lifetime of an association? Is the
= >>> lifetime of the association understood as the lifetime of the >>> configured endpoint identifier?
>>>
>>> Then, when I re-read the text in Section 1 again then I suddenl= y
>>> get the impression that the lifetime of the association actuall= y
>>> does not matter but instead the difference is rather whether th= e
>>> client is public or confidential. Is that true?
>>>
>>> If it isn't true that this is the feature that makes the
>>> distinction between 'dynamic', and 'transient' then the notion o= f
>>> "public" vs. "confidential" client isn't too important for the r= est
>>> of the document.
>>>
>>> Ciao Hannes
>>>
>>>
>>> _______________________________________________ OAuth mailing l= ist
>>> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
>>
>

_______________________________________________
OAuth mailing list
OAuth@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org= /mailman/listinfo/oauth

= --Apple-Mail-1AD6E9DB-960D-457F-9D02-205546547A0D-- From hannes.tschofenig@gmx.net Sun Nov 3 01:28:14 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091FA21F9CE8 for ; Sun, 3 Nov 2013 01:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8dmz-dr6uBl for ; Sun, 3 Nov 2013 01:28:05 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC1121F9C6C for ; Sun, 3 Nov 2013 01:27:56 -0800 (PST) Received: from masham-mac.home ([81.164.176.169]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LhB9P-1Vxfnp2y7b-00oTgb for ; Sun, 03 Nov 2013 10:27:54 +0100 Message-ID: <52761718.2060808@gmx.net> Date: Sun, 03 Nov 2013 10:27:52 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Phil Hunt References: <5274D238.8070803@gmx.net> <49AA7409-C574-43E4-8D44-827092B356B2@oracle.com> In-Reply-To: <49AA7409-C574-43E4-8D44-827092B356B2@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:0ZgIcvPRQJ47CZMzcpbDmw7JFIFeiL+iNuaryEjNMejR6hp9/AD 5Ry7PCz98XPDkC0voQ39cQCkWJJgvWYIygQs9vARDKR6CSI0REcjCpBcj0QBRuRnq8k0NiJ nz6Fl5qz/pRDdk1LAWJ4Ebo4RW81qxlh7zOWO1lWUvo1PIQv0xMf0HEDQFhpLqJZrcMhqC3 jT0xDmfQ4FSthexqcZQEQ== Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Dynamic Client Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 09:28:14 -0000 Hi Phil, you are right that I should have used different terminology, such as the classification that Justin uses in his document (such as 'open registration', 'protected registration') since the term 'enterprise' and 'web' carries a lot of other emotions and baggage that is not relevant to this discussion. What would be good to ensure is that we capture the different classes. We have at least the following cases: * Out-of-band registration of the developer and the client (as we have it with many deployments of OAuth 2.0 today). * Open Registration (where there is no prior interaction between the RP and the IdP). * Then, there is a mixed case (where I would include your softare statements) where other information is used for authorizing the client (or client instance). [The difficulty I had writing these cases while at the same time looking at draft-richer-oauth-dyn-reg-core-00 tells me that the major differences between the different cases are not immediately visible from Appendix B of draft-richer-oauth-dyn-reg-core-00 even though there is a lot of text.] In some sense you have tried your own version of this classification in the software statement document, but as I had noted in my review, I believe you are also not quite there yet. Ciao Hannes Am 02.11.13 17:08, schrieb Phil Hunt: > Hannes, > > Some really good, thought provoking comments! I had not really been > focused as much on financial relationships between SP and client. I > must confess I considered web clients that set up major relations > with service providers. In these cases I dismissed them as a use case > because they would most likely configure manually and actually end up > in the "static" class of clients. Still, I think we should give this > some more careful thought. > > What were you thinking of as a "enterprise" that differentiates with > what we are currently talking about? Enterprise these days has so > much derogatory baggage that it is hard to tell what is being > referred to. > > There is a quality of APIs that 6749 focuses on that registration can > fix. 6749 works well for "monopoly"/"singleton" API providers like > Google, Facebook, etc. Yet there are lots of "open" APIs established > through open source projects, open standards (e.g. Connect), and > commercial cases where customers will deploy their own copies of an > API. I'm not sure this really is "enterprise". Even in the > commercial cases, these APIs are most often made available as "open" > for use by third party developers. For me, this isn't a case of > extending OAuth to support "enterprise", but rather extending OAuth > to support "open" or "multiple-deployment" APIs on the web no matter > where or how they are deployed. > > Phil > > @independentid www.independentid.com phil.hunt@oracle.com > > On 2013-11-02, at 3:21 AM, Hannes Tschofenig > wrote: > >> Hi all, >> >> reading througth various dynamic client registration document I get >> the impression that there is one area of potential disconnect, >> namely in the end user / developer experience. >> >> When OpenID started this concept that a random IdP could talk to a >> random RP it seemed like a great idea. There was no need to >> exchange secrets and go through this complicated introduction >> process between the different parties, which sometimes even >> required business argeements. Those processes were known from >> Kerberos and also from the SAML identity federations. >> >> OpenID looked at the entire step from a technical point of view in >> an attempt to exchange the necessary information and then you were >> done with it. >> >> However, there was a bit more to this whole process, namely the >> entire notion of trust. In particular, there was the problem that >> the IdP would hand out information (personal data) to RPs only >> based on the user's consent. Of course, things could go wrong and >> some RPs misused the data given by the RP. The IdP couldn't really >> do anything about that since it knew nothing about the developer at >> the RP or the RP itself. >> >> So, how does the IdP ensure that it has some way to improve >> security and privacy of their users without handing out just >> everything. Of course, the IdP had it's own interest to know to >> know data is being passed to. >> >> Jumping to OAuth many deployments required developers to register >> and this registration procedure might require lots of information >> (such as credit card number, phone number, agreeing the terms of >> service, etc.). So, in many cases it wasn't purely about giving the >> developer a client-id and a shared secret for the client >> application. >> >> Now, here is the challenge: there are obviously different >> environments developers produce software for (such as the Web, the >> mobile app eco-system, and enterprise environments). They might all >> have different processes and expectations about the entire >> process. >> >> We have pretty much short-cut the entire story to the purely >> technical parts, namely to sending messages around and defining new >> attributes and have done very little in describing the process >> itself that we assume takes place. >> >> I know that you have these processes in your head when you write >> your documents and in discussions I have heard about these >> processes. Unfortunately, they aren't really documented anywhere. I >> guess it is needless to say that the expectations about how >> enterprises plan to deploy software vs. how the same is done for >> the Web is somewhat different. >> >> So, I believe it is useful to chat about these aspects even though >> they may just lead to a few paragraphs in our documents providing >> background information rather than actual normative specification >> text. >> >> Ciao Hannes _______________________________________________ OAuth >> mailing list OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From hannes.tschofenig@gmx.net Sun Nov 3 01:28:18 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79DF21F9C6C for ; Sun, 3 Nov 2013 01:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IORvRO3pa3Kc for ; Sun, 3 Nov 2013 01:28:14 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id DAAA521F9DFB for ; Sun, 3 Nov 2013 01:28:01 -0800 (PST) Received: from masham-mac.home ([81.164.176.169]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MDE6y-1VQp9Y3F4W-00GX3O for ; Sun, 03 Nov 2013 10:28:01 +0100 Message-ID: <5276171E.7060307@gmx.net> Date: Sun, 03 Nov 2013 10:27:58 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Richer, Justin P." References: <5274D238.8070803@gmx.net> <2799AEE6-F443-4591-A3C4-D20258A81AE0@mitre.org> In-Reply-To: <2799AEE6-F443-4591-A3C4-D20258A81AE0@mitre.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:22uuZUP40i+tcBbJJDzmMrbFT/nRakcE04aWDTlD28FPpttA9K9 3KKcwPPnukovC3KpezUTRrvhN6rdTPolptLyw7uvAI79Gf1i10LO3EGrJR9yNkIhi4CY9K2 rRixn+yAGhMqV+g05N4bw52ANIdV1YFQXxL9xzM21IU6EZ0+am+HCbJWpXXzAAuPHc1lUL1 1sFccx6bAatekfNBOwx+Q== Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Dynamic Client Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 09:28:18 -0000 Thanks for sharing your perspective, Justin. This is a good summary of the use cases in the appendix of draft-richer-oauth-dyn-reg-core-00 and draft-ietf-oauth-dyn-reg-14. The text in the appendix is more focuses on the technical aspects but I believe the main difference really is in the user/developer experience in those use cases, which you have summarized in this mail. I wonder whether it would make sense to include this brief summary of the use cases in the introduction section of the document (and point to the more detailed writeup in the appendix). Read through the document I have been to find out what the disconnect in the group has been and my only idea was that it might have something to do with the focus on different scenarios. If that's not the case then I really don't know. Since I am interested to make some progress on this area I am curious about what could be done. Here is what I believe I see: * We have the core specification (with is with draft-richer-oauth-dyn-reg-core-00 quite stripped down to focus on the interaction with the registration endpoint) * We have the software statements document , which are a step that happens before the registration interaction kicks in. I see this as an independent specification that can easily be run before the steps outlined in draft-richer-oauth-dyn-reg-core-00 * We have two approaches for managing registration information, namely draft-richer-oauth-dyn-reg-management and draft-hunt-oauth-scim-client-reg-00 (whereby the latter uses SCIM as a baseline and the former doesn't). I understand the argument that someone who already implements SCIM might as well want to re-use it. Of course, if you don't use SCIM then that argument does not get you too far. In that sense, I could imagine both being valid approach (with suitability for different environments). What I would like to see is how different they are with their on-the-wire behavior since both are supposed to be RESTful APIs * Finally, there was this worry about the stateless nature of the AS (with respect to the clients and their client ids). John had produced an interesting writeup to illustrate that you can accomplish the goal with the current OAuth 2.0 spec when you construct the client-id in a special way. A path forward could be to * go ahead with draft-richer-oauth-dyn-reg-core-00 (with minor updates to create the link to the other documents, such as the software statement). * publish the software statement document * for the approach of managing registration requires a bit of analysis to see whether the two approaches are indeed that different. If they are indeed very different then it might make sense to publish both. However, if they are not that different then we need to make a decision what we want to go further with. We don't need two specifications that are almost identical * I also think we should publish draft-bradley-stateless-oauth-client-00 as an informational document since it seems to be something that people worry about and the document illustrates how to accomplish the desired functionality without normative changes to the OAuth 2.0 protocol. Ciao Hannes Am 03.11.13 05:28, schrieb Richer, Justin P.: > Hannes, > > There are a number of major use cases and expectations that I've kept > in mind throughout the development of this protocol. Some of the > fallout of this is captured in appendix B of the current draft, but > I'd be happy to write them out here: > > > First, the use cases of OpenID Connect and UMA are driving factors, > which shouldn't be surprising since the draft that we have now came > into existence by combining the UMA dynamic registration draft (which > started its life over 3 years ago now) and the OpenID Connect dynamic > registration draft (which is at least 2 years old). In both of these > cases, the trust starts at the end user, who effectively makes the > introductions between the different components. For example, in > Connect's fully open and distributed mode, the end user types in a > web finger address at the RP to point to an IdP that the RP's > potentially never heard of. That RP needs to be able to talk to that > IdP in real time, while the user is still there. Likewise in UMA, the > end user points the client at the API which discovers the AS. Any > kind of step that requires a system administrator or developer to be > involved is a dead stop for the fully distributed cases of these > protocols, since the whole point is to *automate* the process of > registration. The case is even more clear with BlueButton+, a > healthcare data access protocol, where the end user is the patient. > The patient has the right and ability to connect their health care > provider's API (protected by the provider's AS) to a client of the > patient's choosing, even if the provider or the provider's software > vendor has never heard of the client software before. > > That said, there's a "more trusted" middle ground where you get > authorized to call the registration endpoint, and you can show that > by presenting an initial access token as part of that request. We've > taken that mechanism with BlueButton+ and defined our own initial > access token as a signed JWT assertion presented as a bearer > assertion. (There's also a discovery protocol in BB+ that defines how > the AS can validate the assertion.) Large providers, like the Googles > and Facebooks of the world, like to have a relationship with the > developer ahead of time. The developer is effectively issued an > access token to tie their clients back to the developer's account. > There can be a problem with this though, and it's important to think > of the dynamic registration from two perspectives: > > From the perspective of the AS, the protocol is all about introducing > new clients. In this view, you've got an AS with lots of different > client applications trying to talk to it. These might be many copies > of the same code base, or many different code bases, but each > instance needs to be able to present a client_id and client_secret > (or equivalent authentication) that the AS can recognize. In an > enterprise, it's common to think from this perspective because it's > usually the enterprise that's rolling out the AS and wanting to > provide access to a published API to a bunch of clients that may or > may not be known ahead of time. > > From the perspective of the client (which is really to say, an > instance of a client), the protocol is all about introducing the > client to a bunch of different auth servers. This is usually the case > when you've got an "open" API, like OIDC, that may be hosted by any > number of unknown parties that need to be discovered at runtime. One > client can talk to a number of different instantiations of this same > API. This perspective often gets lost when people talk about > deploying auth servers (especially the large internet providers) or > having some kind of trusted registration, like what Google wants to > do with giving developers access tokens. However, I think that this > perspective is going to become more important as we have more > widespread common APIs and better service discovery systems. Note > that in BB+ we have both open and trusted registrations, with the > open registrations MTI. > > > Extensibility of the base draft is also a very important > consideration to me. OAuth works because it's a set of composable > blocks that can be brought together to solve a wide variety of > problems. As such, it's important that the client's metadata be > safely and easily extensible so that specific protocols being > protected by OAuth (like Connect or Blue Button) can easily define > protocol-specific client aspects. This would also be the logical > place to inject Phil's proposed software statement, as an extension > to the client's presented metadata and a means for protecting > particular fields with a signature. Additionally, since OAuth has > many different methods of clients authenticating, the draft defines a > registry to allow for specific OAuth-protected protocols and systems > to define different auth methods, like Connect's private_key_jwt and > client_secret_jwt methods that are more specific to how Connect > defines its interactions. I'm sure there will be other methods in the > future, too. > > > Finally, the ability of the client to manage the metadata that's > attached to a client_id over time is important in some use cases. > Fundamentally, the registration process is the "Create" verb, and the > "Read/Update/Delete" verbs are a short step after that to implement. > It's become clear to me that if your authorization servers are fully > stateless, or if you believe that all of the metadata properties of a > given client (or even piece of software with multiple instances), > then the management API doesn't make any sense. However, neither of > these assumptions are universal, and with the right components, we > can have a system that can be composed in different ways to fit all > of these use cases. > > -- Justin > > On Nov 2, 2013, at 6:21 AM, Hannes Tschofenig > wrote: > >> Hi all, >> >> reading througth various dynamic client registration document I get >> the impression that there is one area of potential disconnect, >> namely in the end user / developer experience. >> >> When OpenID started this concept that a random IdP could talk to a >> random RP it seemed like a great idea. There was no need to >> exchange secrets and go through this complicated introduction >> process between the different parties, which sometimes even >> required business argeements. Those processes were known from >> Kerberos and also from the SAML identity federations. >> >> OpenID looked at the entire step from a technical point of view in >> an attempt to exchange the necessary information and then you were >> done with it. >> >> However, there was a bit more to this whole process, namely the >> entire notion of trust. In particular, there was the problem that >> the IdP would hand out information (personal data) to RPs only >> based on the user's consent. Of course, things could go wrong and >> some RPs misused the data given by the RP. The IdP couldn't really >> do anything about that since it knew nothing about the developer at >> the RP or the RP itself. >> >> So, how does the IdP ensure that it has some way to improve >> security and privacy of their users without handing out just >> everything. Of course, the IdP had it's own interest to know to >> know data is being passed to. >> >> Jumping to OAuth many deployments required developers to register >> and this registration procedure might require lots of information >> (such as credit card number, phone number, agreeing the terms of >> service, etc.). So, in many cases it wasn't purely about giving the >> developer a client-id and a shared secret for the client >> application. >> >> Now, here is the challenge: there are obviously different >> environments developers produce software for (such as the Web, the >> mobile app eco-system, and enterprise environments). They might all >> have different processes and expectations about the entire >> process. >> >> We have pretty much short-cut the entire story to the purely >> technical parts, namely to sending messages around and defining new >> attributes and have done very little in describing the process >> itself that we assume takes place. >> >> I know that you have these processes in your head when you write >> your documents and in discussions I have heard about these >> processes. Unfortunately, they aren't really documented anywhere. I >> guess it is needless to say that the expectations about how >> enterprises plan to deploy software vs. how the same is done for >> the Web is somewhat different. >> >> So, I believe it is useful to chat about these aspects even though >> they may just lead to a few paragraphs in our documents providing >> background information rather than actual normative specification >> text. >> >> Ciao Hannes _______________________________________________ OAuth >> mailing list OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From sakimura@gmail.com Sun Nov 3 05:05:05 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF69011E81FB for ; Sun, 3 Nov 2013 05:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P90BkcqjIF2o for ; Sun, 3 Nov 2013 05:05:04 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDD511E8135 for ; Sun, 3 Nov 2013 05:05:03 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id u14so4639436lbd.22 for ; Sun, 03 Nov 2013 05:05:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=21Qlz9m70u/w/xJqU/rE/LZNKKrRLMxlHhKgcoYfglE=; b=W4zAfss//X6bPakzttpwPd/ARITeWnqk0MtGXFqfvjyOQKobB5Oi21Rb6JKdTPQxdb zUfF5hZ1rKotjAYI4LPCDXCdTonU80YXodsOdflggKLvaCPO2lsIptuJ9oa3pGRGhcWN VxntuW6pNC+78q8DPAVM8dJeHuSWfFGn5Hjf6Z4x/OL359ROA3KLRN2sd2FfizeSvQng LmIgHjegeY0k6DA/qctwQFlHgD5HYQ2c4NmDlM5OBMZy0KC0YXsNxYcwuScrfrTgpH4X b6jLpocVei+ZPgv0BXwuBS6r9vsVjsxFwM8hLyGyW4gx5hIVxSl1Ivfhi6YJ9rBLqUr4 sF1w== MIME-Version: 1.0 X-Received: by 10.112.136.65 with SMTP id py1mr7834195lbb.4.1383483902917; Sun, 03 Nov 2013 05:05:02 -0800 (PST) Received: by 10.112.134.38 with HTTP; Sun, 3 Nov 2013 05:05:02 -0800 (PST) In-Reply-To: References: Date: Sun, 3 Nov 2013 22:05:02 +0900 Message-ID: From: Nat Sakimura To: Phil Hunt Content-Type: multipart/alternative; boundary=089e0115f6c496034304ea4572e4 Cc: oauth list Subject: Re: [OAUTH-WG] Client Association alternative to Dyn Reg and stateless oauth client X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 13:05:06 -0000 --089e0115f6c496034304ea4572e4 Content-Type: text/plain; charset=ISO-8859-1 Thanks Phil. This is largely in-line with what I have been looking for since 2011 or so. Instead of "software id", I was using the term "client class id" but that would be more or less equivalent, though I like "client class id" better than "software id" as a piece of software may imply client instance as well. I further was thinking that "client class id" should be a URI from which the authorization server can pull the "software statement"/"class properties" so that signing it would be optional and it could simply be a plain JSON. That would make it easier to fix the "software statement" bugs and adding more values (e.g. more language support) at a later date. As to the "association" is concerned, it would be really nice if the response includes the link relationship in the response JSON like in http://tools.ietf.org/html/draft-sakimura-oauth-meta . By doing so, the client instance can learn which authorization endpoint and so on that it should use [1]. This would allow the server to assign different endpoints to different client instances for scalability, security, billing and all sorts of other reasons. It would also achieve HATEOAS. As to the relationship with the dynreg draft is concerned, I kind of see dynreg as an API to talk to the software publisher. [1] I think it would be better return the discovery endpoint and have the client figure out where is its authorization endpoint than returning authorization endpoint directly but it can be either way. Cheers, Nat 2013/11/2 Phil Hunt > I would like to encourage people to read the client association draft > before monday. > http://tools.ietf.org/html/draft-hunt-oauth-client-association-00.txt and > the related > http://tools.ietf.org/html/draft-hunt-oauth-software-statement-00.txt > > Most of the draft just focuses on background and taxonomy. If you are not > interested, focus in on the dynamic association section. I believe you will > find this alternate stateless approach to be very simple to implement and > uses a well established pattern. > > My position is that while the new approach represents a major change to > OIDC implementors, the benefits outweigh the costs as it will make Connect > much easier to support for service providers. > > The key difference in approaches is that the software statement serves as > a way to lock-down registration profiles that allow servers (and their > policy systems) to recognize different types of client software. Note > that nothing about using software statements prevents developers from > self-asserting registration. Those scenarios can continue to work. The > key benefit to service providers and client developers is that the number > of variations for registration options is dramatically reduced. The > registration becomes a simple assertion swap with any allowable per-client > overrides as an exception rather than the norm. > > IOW -- client association places different emphasis on what happens when. > Client association assumes software characteristics are known at packaging > time and does not vary widely (from the client side) other than having to > handle different authentication policies of the various service providers. > > I've already spent more text here explaining the difference than the core > of the draft takes to explain the registration. So please read the draft > before our discussion on monday. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --089e0115f6c496034304ea4572e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Phil.=A0

This is largely in-line= with what I have been looking for since 2011 or so.=A0
Instead o= f "software id", I was using the term "client class id"= but that would be more or less equivalent, though I like "client clas= s id" better than "software id" as a piece of software may i= mply client instance as well.=A0

I further was thinking that "client class id"= should be a URI from which the authorization server can pull the "sof= tware statement"/"class properties" so that signing it would= be optional and it could simply be a plain JSON. That would make it easier= to fix the "software statement" bugs and adding more values (e.g= . more language support) at a later date.=A0

As to the "association" is concerned, it woul= d be really nice if the response includes the link relationship in the resp= onse JSON like in=A0http://tools.ietf.org/html/draft-sakimura-oauth-meta=A0. By d= oing so, the client instance can learn which authorization endpoint and so = on that it should use [1]. This would allow the server to assign different = endpoints to different client instances for scalability, security, billing = and all sorts of other reasons. It would also achieve HATEOAS.=A0

As to the relationship with the dynreg draft is concern= ed, I kind of see dynreg as an API to talk to the software publisher.=A0

[1] I think it would be better return the discovery = endpoint and have the client figure out where is its authorization endpoint= than returning authorization endpoint directly but it can be either way.= =A0

Cheers,=A0

Nat


2013/11/2 Phil Hu= nt <phil.hunt@oracle.com>
I would = like to encourage people to read the client association draft before monday= .=A0http://tools.ietf.org/html/draft-hunt-oauth-cl= ient-association-00.txt and the related=A0http= ://tools.ietf.org/html/draft-hunt-oauth-software-statement-00.txt

Most of the draft just focuses on background and taxonomy. I= f you are not interested, focus in on the dynamic association section. I be= lieve you will find this alternate stateless approach to be very simple to = implement and uses a well established pattern.

My position is that while the new approach represents a= major change to OIDC implementors, the benefits outweigh the costs as it w= ill make Connect much easier to support for service providers.

The key difference in approaches is that the software statem= ent serves as a way to lock-down registration profiles that allow servers (= and their policy systems) to recognize different types of client software. = =A0 Note that nothing about using software statements prevents developers f= rom self-asserting registration. =A0Those scenarios can continue to work. = =A0 The key benefit to service providers and client developers is that the = number of variations for registration options is dramatically reduced. The = registration becomes a simple assertion swap with any allowable per-client = overrides as an exception rather than the norm.

IOW -- client association places different emphasis on = what happens when. =A0Client association assumes software characteristics a= re known at packaging time and does not vary widely (from the client side) = other than having to handle different authentication policies of the variou= s service providers.

I've already spent more text here explaining the di= fference than the core of the draft takes to explain the registration. So p= lease read the draft before our discussion on monday.



_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--089e0115f6c496034304ea4572e4-- From bcampbell@pingidentity.com Sun Nov 3 08:36:53 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E12B11E815F for ; Sun, 3 Nov 2013 08:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.865 X-Spam-Level: X-Spam-Status: No, score=-5.865 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9Jq2J35LvWr for ; Sun, 3 Nov 2013 08:36:43 -0800 (PST) Received: from na3sys009aog131.obsmtp.com (na3sys009aog131.obsmtp.com [74.125.149.247]) by ietfa.amsl.com (Postfix) with ESMTP id 431ED11E81FE for ; Sun, 3 Nov 2013 08:36:35 -0800 (PST) Received: from mail-ie0-f172.google.com ([209.85.223.172]) (using TLSv1) by na3sys009aob131.postini.com ([74.125.148.12]) with SMTP ID DSNKUnZ7kKIELnL8bMPeVgZ4nUM1xRCe3HQ8@postini.com; Sun, 03 Nov 2013 08:36:35 PST Received: by mail-ie0-f172.google.com with SMTP id tp5so10999182ieb.17 for ; Sun, 03 Nov 2013 08:36:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=2wMjmwuGdOE/fR+aaYSwJizL52Rc4yI1i/HRK7JpprA=; b=Sb+OxF1fgVrgUlkmNW3iz901Ld4V9cszMFZpg9ZfVxMt6VWNsq2scWRixw8JX0x8wW P3p+WXIzvB0gcmEVN+9gDla2ktuk79IWf7g/WloSIEZJO1qzy0sbcBG3s06Vexql5/AK vQjXmnBTdl7F3cxhNnaARl6YOiNaVfGwUy+GpZu3v0zrCB0q1oKLZQ2Ehzo6p2JGrP+w KdbHKFcQd9TwSGVIPT3OZ1KNKZCrBJ06Ouzp2VT5Lc8Ki5RitZYW0HnN8DokLNw5HI9d yWn6ZKsCR8D6jJ9dgqNPstYkJBsPFzKqOomwXOZ1r6MtuhsUnUvgPqDVKeEMzzX9q+U6 hu7Q== X-Gm-Message-State: ALoCoQntHxJNm9cKgVm8NYfzJV+iMQFIx4epnfCBP/rEm4PRG4m8YEpNPyypYeI6IBXvBMBvsdKN7T7+Z9/BD11G/l94b/7Lmb6RvszzhP1bT4XhdpKPHuZepePQ9c6fTVVDLiAsr355T1iwCp5/J9slZoYElT5crw== X-Received: by 10.50.1.102 with SMTP id 6mr9381265igl.0.1383496592422; Sun, 03 Nov 2013 08:36:32 -0800 (PST) X-Received: by 10.50.1.102 with SMTP id 6mr9381259igl.0.1383496592245; Sun, 03 Nov 2013 08:36:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.245.233 with HTTP; Sun, 3 Nov 2013 08:36:02 -0800 (PST) From: Brian Campbell Date: Sun, 3 Nov 2013 08:36:02 -0800 Message-ID: To: oauth , "" Content-Type: multipart/alternative; boundary=047d7bd770a4ede5c504ea486681 Subject: [OAUTH-WG] -00 of draft-bradley-stateless-oauth-client X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 16:36:56 -0000 --047d7bd770a4ede5c504ea486681 Content-Type: text/plain; charset=ISO-8859-1 Some musings on http://tools.ietf.org/html/draft-bradley-stateless-oauth-client-00 Abstract: "... allowing for fully stateless operation." --> saying that the statelessness is on the AS side might avoid some confusion. The client is still going to have to maintain state. The kid is header rather than a claim. "The issuer SHOULD sign the JWT with JWS ... issuer MAY encrypt the JWT with JWE." --> this text seems a little off given that the most common case, I'd think, would be an AS who issues these client id JWTs only for its own consumption using JWE's AES_CBC_HMAC_SHA2 which gives encryption and integrity protection. Does the relationship between the "iat" and "exp" claims here and the "client_secret_expires_at" and "client_id_issued_at" parameters of dyn reg need to be explained or explored more? Strikes me as potentially problematic. And what happens when one of these JWT client ids expires or needs to be updated? Or the keys used to create or verify them expire? I know the answer thus far has been that the client will just have to get a new one. But I feel like that might be too limiting in practice. I'd like to further pursue understanding/defining how these kinds of client ids might be used in conjunction with a longer lived way to identify the client that allows the client id (i.e. the metadata) to change but can allow correlation across such changes (the sub claim in this doc even suggests that a client might have such an identifier). As was pointed out in another review, there's a difference between documenting how it's possible for an AS to issue "stateless" client ids for its own use and defining something that allows for some other party to issue such ids. It may make sense to discuss them in the same document but I believe it'd be valuable to have the doc acknowledge and address the difference more. --047d7bd770a4ede5c504ea486681 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Abstract:= "... allowing for fully stateless operation." --> saying that the statelessness is on th= e AS side might avoid some confusion. The client is still going to have to = maintain state.

The kid is header rather than a claim.

"The issuer SHOULD sign the JWT with JWS ...=A0 issuer MAY encrypt= the JWT with JWE." --> this text seems a little off given that the= most common case, I'd think, would be an AS who issues these client id= JWTs only for its own consumption using JWE's AES_CBC_HMAC_SHA2 which = gives encryption and integrity protection.

Does the relationship between the "iat" and "exp" c= laims here and the "client_secret_expires_at" and "client_id= _issued_at" parameters of dyn reg need to be explained or explored mor= e? Strikes me as potentially problematic.

And what happens when one of these JWT client ids expires or need= s to be updated? Or the keys used to create or verify them expire? I know t= he answer thus far has been that the client will just have to get a new one= . But I feel like that might be too limiting in practice. I'd like to f= urther pursue understanding/defining how these kinds of client ids might be= used in conjunction with a longer lived way to identify the client that al= lows the client id (i.e. the metadata) to change but can allow correlation = across such changes (the sub claim in this doc even suggests that a client = might have such an identifier).

As was pointed out in another review, there's a differen= ce between documenting how it's possible for an AS to issue "state= less" client ids for its own use and defining something that allows fo= r some other party to issue such ids. It may make sense to discuss them in = the same document but I believe it'd be valuable to have the doc acknow= ledge and address the difference more.




=A0
--047d7bd770a4ede5c504ea486681-- From ve7jtb@ve7jtb.com Sun Nov 3 09:04:14 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAD821E80FA for ; Sun, 3 Nov 2013 09:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUR9lluLpnq5 for ; Sun, 3 Nov 2013 09:04:09 -0800 (PST) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9B211E815F for ; Sun, 3 Nov 2013 09:04:09 -0800 (PST) Received: by mail-pd0-f178.google.com with SMTP id x10so5809325pdj.37 for ; Sun, 03 Nov 2013 09:04:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Ota6xYxIYjkY2lNiVbwmYyZK+QOc+WNI0pWljI/zuOI=; b=lO4H0Jce142cKyGOfh4BHN7vxqzngjFTitu0SC0vuKm0RZirKGHcTNTYk3TmyVu6Sv UCbekg+sfrQsJ54ECzTdNsji9BWbZOWKw3apLIwKLxFSXEBxnvtxnqRooPvDtv2C9Zph rM71pK461nVq2vgE4Ltw9nYVi/+SNkJPkpDu7gUOp7XFkskPH48/RKx+QOpzju42v1Q4 ambMSnHm6hA88Gx/WEHp6+FhOIQjBA2c+iqBWS5jKCensvQU6R6i0b/40HWimzqsHafX VQK3RjC6QXrhP61ORdXqkdsqQtZLC0l5iZR5YF+3Qn4egoWCWSZd2zpdY817A8/h0Ibs wWtQ== X-Gm-Message-State: ALoCoQn/oCr0lwjqPM/5F+Gb2Kz2l3qaCnaotKHbG2ZV3ng4XzFRecuwyPSuprqKIHaWCSeMVDiJ X-Received: by 10.68.251.133 with SMTP id zk5mr13559755pbc.69.1383498247722; Sun, 03 Nov 2013 09:04:07 -0800 (PST) Received: from [192.168.5.199] (199-91-80-194.ip.van.radiant.net. [199.91.80.194]) by mx.google.com with ESMTPSA id ye1sm27216371pab.19.2013.11.03.09.04.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 09:04:06 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_F60D0755-CCE6-4196-B7CC-F9EC2BB585C2"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: John Bradley In-Reply-To: Date: Sun, 3 Nov 2013 09:04:01 -0800 Message-Id: References: To: Brian Campbell X-Mailer: Apple Mail (2.1816) Cc: "" , oauth Subject: Re: [OAUTH-WG] [Openid-specs-ab] -00 of draft-bradley-stateless-oauth-client X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 17:04:14 -0000 --Apple-Mail=_F60D0755-CCE6-4196-B7CC-F9EC2BB585C2 Content-Type: multipart/alternative; boundary="Apple-Mail=_1C4EF1B8-7836-4AEB-937B-1E74D13A2FBA" --Apple-Mail=_1C4EF1B8-7836-4AEB-937B-1E74D13A2FBA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 YEs in my other response to Hannes I noted that in the simple case of a = one to one relationship between a AS and a registration server = AES_CBC_HMAC_SHA2 is probably the best way to do integrity(must not say = signing or the crypto wonks go nuts) and confidentiality if a symetric = secret is included in the JWT. The need for confidentiality goes away if the client is using a = asymmetric key to authenticate. Separately I have been dealing with several OAuth clients (Websites) = that have been compromised and lost all of there OAuth 1 tokens and = secrets as well as all of there Oauth 2 tokens. We can put it down to bad security, but having long lived access tokens = and there secrets hanging around in databases is a tempting target. =20 It is also challenging for a client to protect there symmetric client = secret in these cases as it is typically in some file on the disk. There may at some point be a push to use asymmetric keys from a HSM to = secure access to the token endpoint and keep the lifetime of the access = tokens short. One thing that is a limitation of encoding information in the client_id = is that we don't currently allow the client_id to change during updated = in client registration. If we did then the JWT could contain some fixed id for the client that = the AS would use as the key for authorizations. I was trying to stay inside the scope of the current drafts. =20 Our options are to allow client_id to change this requires only a = change in dynamic registration, and not the rest of the client logic, or = to crate a separate parameter for client_assertion that would contain = the signed information including the client_id sending the client_id = twice. I think allowing the client_id to be reference or assertion as = determined by the AS is more in keeping with what we are doing with = access tokens. =20 I don't think that should require any change to clients, though it = would require change to server logic to treat the incoming client_id as = a reference or assertion to the actual client identifier rather than = always being a literal. I think it is worth discussing. John B. On Nov 3, 2013, at 8:36 AM, Brian Campbell = wrote: > Some musings on = http://tools.ietf.org/html/draft-bradley-stateless-oauth-client-00 >=20 > Abstract: "... allowing for fully stateless operation." --> saying = that the statelessness is on the AS side might avoid some confusion. The = client is still going to have to maintain state.=20 >=20 > The kid is header rather than a claim. >=20 > "The issuer SHOULD sign the JWT with JWS ... issuer MAY encrypt the = JWT with JWE." --> this text seems a little off given that the most = common case, I'd think, would be an AS who issues these client id JWTs = only for its own consumption using JWE's AES_CBC_HMAC_SHA2 which gives = encryption and integrity protection. >=20 > Does the relationship between the "iat" and "exp" claims here and the = "client_secret_expires_at" and "client_id_issued_at" parameters of dyn = reg need to be explained or explored more? Strikes me as potentially = problematic. >=20 > And what happens when one of these JWT client ids expires or needs to = be updated? Or the keys used to create or verify them expire? I know the = answer thus far has been that the client will just have to get a new = one. But I feel like that might be too limiting in practice. I'd like to = further pursue understanding/defining how these kinds of client ids = might be used in conjunction with a longer lived way to identify the = client that allows the client id (i.e. the metadata) to change but can = allow correlation across such changes (the sub claim in this doc even = suggests that a client might have such an identifier). >=20 > As was pointed out in another review, there's a difference between = documenting how it's possible for an AS to issue "stateless" client ids = for its own use and defining something that allows for some other party = to issue such ids. It may make sense to discuss them in the same = document but I believe it'd be valuable to have the doc acknowledge and = address the difference more. >=20 >=20 >=20 >=20 > =20 > _______________________________________________ > Openid-specs-ab mailing list > Openid-specs-ab@lists.openid.net > http://lists.openid.net/mailman/listinfo/openid-specs-ab --Apple-Mail=_1C4EF1B8-7836-4AEB-937B-1E74D13A2FBA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 YEs in = my other response to Hannes I noted that in the simple case of a one to = one relationship between a AS and a registration server = AES_CBC_HMAC_SHA2 is probably the best way to do integrity(must not say = signing or the crypto wonks go nuts)  and confidentiality if a = symetric secret is included in the JWT.

The need for = confidentiality goes away if the client is using a asymmetric key to = authenticate.

Separately I have been dealing = with several OAuth clients (Websites) that have been compromised and = lost all of there OAuth 1 tokens and secrets as well as all of there = Oauth 2 tokens.
We can put it down to bad security, but having = long lived access tokens and there secrets hanging around in databases = is a tempting target.  
It is also challenging for a = client to protect there symmetric client secret in these cases as it is = typically in some file on the disk.

There may = at some point be a push to use asymmetric keys from a HSM to secure = access to the token endpoint and keep the lifetime of the access tokens = short.

One thing that is a limitation of = encoding information in the client_id is that we don't currently allow = the client_id to change during updated in client = registration.
If we did then the JWT could contain some fixed = id for the client that the AS would use as the key for = authorizations.

I was trying to stay inside the = scope of the current drafts.    
Our options are to = allow client_id to change  this requires only a change in dynamic = registration, and not the rest of the client logic, or to crate a = separate parameter for client_assertion that would contain the signed = information including the client_id sending the client_id = twice.

I think allowing the client_id to be = reference or assertion  as determined by the AS is more in keeping = with what we are doing with access tokens.  
I don't = think that should require any change to clients,  though it would = require change to server logic to treat the incoming client_id as a = reference or assertion to the actual client identifier rather than = always being a literal.

I think it is worth = discussing.

John = B.



On = Nov 3, 2013, at 8:36 AM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:


Abstract: "... allowing for fully stateless operation." --> saying that the statelessness is on the = AS side might avoid some confusion. The client is still going to have to = maintain state.

The kid is header rather than a claim.

"The issuer SHOULD sign the JWT with JWS ...  issuer MAY = encrypt the JWT with JWE." --> this text seems a little off given = that the most common case, I'd think, would be an AS who issues these = client id JWTs only for its own consumption using JWE's = AES_CBC_HMAC_SHA2 which gives encryption and integrity protection.

Does the relationship between the "iat" and "exp" claims here and = the "client_secret_expires_at" and "client_id_issued_at" parameters of = dyn reg need to be explained or explored more? Strikes me as potentially = problematic.

And what happens when one of these JWT client ids expires or = needs to be updated? Or the keys used to create or verify them expire? I = know the answer thus far has been that the client will just have to get = a new one. But I feel like that might be too limiting in practice. I'd = like to further pursue understanding/defining how these kinds of client = ids might be used in conjunction with a longer lived way to identify the = client that allows the client id (i.e. the metadata) to change but can = allow correlation across such changes (the sub claim in this doc even = suggests that a client might have such an identifier).

As was pointed out in another review, there's a = difference between documenting how it's possible for an AS to issue = "stateless" client ids for its own use and defining something that = allows for some other party to issue such ids. It may make sense to = discuss them in the same document but I believe it'd be valuable to have = the doc acknowledge and address the difference more.




 
_______________________________________________
Openid-specs-ab = mailing list
Openid-specs-ab@lists.ope= nid.net
http://lists.openid.net/mailman/listinfo/openid-specs-ab

= --Apple-Mail=_1C4EF1B8-7836-4AEB-937B-1E74D13A2FBA-- --Apple-Mail=_F60D0755-CCE6-4196-B7CC-F9EC2BB585C2 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMTAzMTcwNDAyWjAjBgkqhkiG9w0BCQQxFgQUFLJhseq/ 6GAg8wRcJvXzROSIdAkwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAeU+aitYUrWlnenD//2Dvcom3FyjUIhw6QiIXcPJl oUyxxtq1QuYBvYFeGd8uHSwfa8VPGMKHX/E2lCEBNpVG9YZGHC3QXgijP9UfIPFFasF9t577noH/ e5ITz8JGnAXPCJTAOw5rxceBykNrDhEyrGXuur2VCeJiwtb6Pxj/7bkarI70MuuHeaNabfXqeoib zF+7DddeBj+CVTvyitCrTFnd9hWbVEmG2XGX3AaaNS+xH/WAkCOW7PtiEt+XE3eiK4II8WmJUKXX cxj+i5pwq0sk0Y1PFgdUy74k2IRSUnKKZpXUT8rzoYPYNAy1zVinEZatiAFtDH13J43N837eoAAA AAAAAA== --Apple-Mail=_F60D0755-CCE6-4196-B7CC-F9EC2BB585C2-- From phil.hunt@oracle.com Sun Nov 3 10:13:20 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF97C11E82CA for ; Sun, 3 Nov 2013 10:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.603 X-Spam-Level: X-Spam-Status: No, score=-5.603 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJxthTNy2WSD for ; Sun, 3 Nov 2013 10:13:15 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id C9E8411E80F8 for ; Sun, 3 Nov 2013 10:13:15 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA3IDD2c008927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 3 Nov 2013 18:13:14 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA3IDC57004951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Nov 2013 18:13:13 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA3IDC5L004948; Sun, 3 Nov 2013 18:13:12 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 03 Nov 2013 10:13:12 -0800 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-C0B8F3D3-5817-459D-9A1C-7EA351DC0654 Content-Transfer-Encoding: 7bit Message-Id: <0E4AEA37-67BC-478D-B7BC-ED7D5558416F@oracle.com> X-Mailer: iPhone Mail (11B511) From: Phil Hunt Date: Sun, 3 Nov 2013 10:13:09 -0800 To: Nat Sakimura X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: oauth list Subject: Re: [OAUTH-WG] Client Association alternative to Dyn Reg and stateless oauth client X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 18:13:21 -0000 --Apple-Mail-C0B8F3D3-5817-459D-9A1C-7EA351DC0654 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Nat=20 I think software_id was equiv to class_id. The statement is intended to "loc= k" the reg profile between instances.=20 The url returned could have another meta attr indicating what type of endpoi= nt it is. Eg. Dyn reg, scim etc.=20 Phil > On Nov 3, 2013, at 5:05, Nat Sakimura wrote: >=20 > Thanks Phil.=20 >=20 > This is largely in-line with what I have been looking for since 2011 or so= .=20 > Instead of "software id", I was using the term "client class id" but that w= ould be more or less equivalent, though I like "client class id" better than= "software id" as a piece of software may imply client instance as well.=20 >=20 > I further was thinking that "client class id" should be a URI from which t= he authorization server can pull the "software statement"/"class properties"= so that signing it would be optional and it could simply be a plain JSON. T= hat would make it easier to fix the "software statement" bugs and adding mor= e values (e.g. more language support) at a later date.=20 >=20 > As to the "association" is concerned, it would be really nice if the respo= nse includes the link relationship in the response JSON like in http://tools= .ietf.org/html/draft-sakimura-oauth-meta . By doing so, the client instance c= an learn which authorization endpoint and so on that it should use [1]. This= would allow the server to assign different endpoints to different client in= stances for scalability, security, billing and all sorts of other reasons. I= t would also achieve HATEOAS.=20 >=20 > As to the relationship with the dynreg draft is concerned, I kind of see d= ynreg as an API to talk to the software publisher.=20 >=20 > [1] I think it would be better return the discovery endpoint and have the c= lient figure out where is its authorization endpoint than returning authoriz= ation endpoint directly but it can be either way.=20 >=20 > Cheers,=20 >=20 > Nat >=20 >=20 > 2013/11/2 Phil Hunt >> I would like to encourage people to read the client association draft bef= ore monday. http://tools.ietf.org/html/draft-hunt-oauth-client-association-0= 0.txt and the related http://tools.ietf.org/html/draft-hunt-oauth-software-s= tatement-00.txt >>=20 >> Most of the draft just focuses on background and taxonomy. If you are not= interested, focus in on the dynamic association section. I believe you will= find this alternate stateless approach to be very simple to implement and u= ses a well established pattern. >>=20 >> My position is that while the new approach represents a major change to O= IDC implementors, the benefits outweigh the costs as it will make Connect mu= ch easier to support for service providers. >>=20 >> The key difference in approaches is that the software statement serves as= a way to lock-down registration profiles that allow servers (and their poli= cy systems) to recognize different types of client software. Note that not= hing about using software statements prevents developers from self-asserting= registration. Those scenarios can continue to work. The key benefit to s= ervice providers and client developers is that the number of variations for r= egistration options is dramatically reduced. The registration becomes a simp= le assertion swap with any allowable per-client overrides as an exception ra= ther than the norm. >>=20 >> IOW -- client association places different emphasis on what happens when.= Client association assumes software characteristics are known at packaging= time and does not vary widely (from the client side) other than having to h= andle different authentication policies of the various service providers. >>=20 >> I've already spent more text here explaining the difference than the core= of the draft takes to explain the registration. So please read the draft be= fore our discussion on monday. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en --Apple-Mail-C0B8F3D3-5817-459D-9A1C-7EA351DC0654 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Nat 

I think software_id was equiv to class_id. The statement is intended to "lock" the reg profile between instances. 

The url returned could have another meta attr indicating what type of endpoint it is. Eg. Dyn reg, scim etc. 

Phil

On Nov 3, 2013, at 5:05, Nat Sakimura <sakimura@gmail.com> wrote:

Thanks Phil. 

This is largely in-line with what I have been looking for since 2011 or so. 
Instead of "software id", I was using the term "client class id" but that would be more or less equivalent, though I like "client class id" better than "software id" as a piece of software may imply client instance as well. 

I further was thinking that "client class id" should be a URI from which the authorization server can pull the "software statement"/"class properties" so that signing it would be optional and it could simply be a plain JSON. That would make it easier to fix the "software statement" bugs and adding more values (e.g. more language support) at a later date. 

As to the "association" is concerned, it would be really nice if the response includes the link relationship in the response JSON like in http://tools.ietf.org/html/draft-sakimura-oauth-meta . By doing so, the client instance can learn which authorization endpoint and so on that it should use [1]. This would allow the server to assign different endpoints to different client instances for scalability, security, billing and all sorts of other reasons. It would also achieve HATEOAS. 

As to the relationship with the dynreg draft is concerned, I kind of see dynreg as an API to talk to the software publisher. 

[1] I think it would be better return the discovery endpoint and have the client figure out where is its authorization endpoint than returning authorization endpoint directly but it can be either way. 

Cheers, 

Nat


2013/11/2 Phil Hunt <phil.hunt@oracle.com>
I would like to encourage people to read the client association draft before monday. http://tools.ietf.org/html/draft-hunt-oauth-client-association-00.txt and the related http://tools.ietf.org/html/draft-hunt-oauth-software-statement-00.txt

Most of the draft just focuses on background and taxonomy. If you are not interested, focus in on the dynamic association section. I believe you will find this alternate stateless approach to be very simple to implement and uses a well established pattern.

My position is that while the new approach represents a major change to OIDC implementors, the benefits outweigh the costs as it will make Connect much easier to support for service providers.

The key difference in approaches is that the software statement serves as a way to lock-down registration profiles that allow servers (and their policy systems) to recognize different types of client software.   Note that nothing about using software statements prevents developers from self-asserting registration.  Those scenarios can continue to work.   The key benefit to service providers and client developers is that the number of variations for registration options is dramatically reduced. The registration becomes a simple assertion swap with any allowable per-client overrides as an exception rather than the norm.

IOW -- client association places different emphasis on what happens when.  Client association assumes software characteristics are known at packaging time and does not vary widely (from the client side) other than having to handle different authentication policies of the various service providers.

I've already spent more text here explaining the difference than the core of the draft takes to explain the registration. So please read the draft before our discussion on monday.



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--Apple-Mail-C0B8F3D3-5817-459D-9A1C-7EA351DC0654-- From bcampbell@pingidentity.com Sun Nov 3 10:26:41 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3BB21E809F for ; Sun, 3 Nov 2013 10:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.879 X-Spam-Level: X-Spam-Status: No, score=-5.879 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id We6pO69R0nZ4 for ; Sun, 3 Nov 2013 10:26:37 -0800 (PST) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by ietfa.amsl.com (Postfix) with ESMTP id 13E0E11E82CD for ; Sun, 3 Nov 2013 10:26:36 -0800 (PST) Received: from mail-ie0-f173.google.com ([209.85.223.173]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKUnaVXNwyAqfxDPSMDAcsyuF1ZYvbAe7i@postini.com; Sun, 03 Nov 2013 10:26:37 PST Received: by mail-ie0-f173.google.com with SMTP id u16so11133141iet.32 for ; Sun, 03 Nov 2013 10:26:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=GwnPB0oIIzrZSqKo5FBZjYAmPpIyFrGlRZmNnPKEjzw=; b=bzOXnULts8DDp+pfVrq9R4zuy5Y4jgWZ4nUiGWq0pKMPBsUeRYy7WSNabKOcqUSpxu RK9PHCq2cd5gw/HSNsJ76Gy0u1WP9ElDj58Ve77/HuS/59wmeydYLLZ+pIRrP9z5zwNG x6nwsy2NShWXdNh4G6xX+bI1KnGtH6qe9Alr0eF6kieMdpOxdYNLvoGOWsupeEsub84Q dkK2qEwIMWmBqR+1qEfoKvcL/kl5u+gB6iB6uvLgiJpl1CoDTxoHseeVh9bsueoYqXq7 mRgcmT310msIb0BWhq3CqF7X/Dy/yUVK1ekEAl4r5YNGLmQkjOB9kWH4dRMFnrafX2Zs A3WQ== X-Gm-Message-State: ALoCoQk7D6dVMivnBJakpCKIrAkkvvegpU1dPNpU3kRaKDCWG6RQGG29tLLrGkYGvCqwLsdqJPFyHbdY5hOzlU9bn78DYPQ0I1VuMk/mPjHIz20Jee436wazylrg7VYArD/EV90qlLeCqV/iu9FOBIw12HTSVipspQ== X-Received: by 10.50.126.74 with SMTP id mw10mr9575366igb.24.1383503196413; Sun, 03 Nov 2013 10:26:36 -0800 (PST) X-Received: by 10.50.126.74 with SMTP id mw10mr9575357igb.24.1383503196267; Sun, 03 Nov 2013 10:26:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.245.233 with HTTP; Sun, 3 Nov 2013 10:26:06 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Sun, 3 Nov 2013 10:26:06 -0800 Message-ID: To: John Bradley Content-Type: text/plain; charset=ISO-8859-1 Cc: "" , oauth Subject: Re: [OAUTH-WG] [Openid-specs-ab] -00 of draft-bradley-stateless-oauth-client X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 18:26:41 -0000 inline below... On Sun, Nov 3, 2013 at 9:04 AM, John Bradley wrote: > YEs in my other response to Hannes I noted that in the simple case of a one > to one relationship between a AS and a registration server AES_CBC_HMAC_SHA2 > is probably the best way to do integrity(must not say signing or the crypto > wonks go nuts) and confidentiality if a symetric secret is included in the > JWT. I think we agree on this. But the text in -00 of the document doesn't reflect that situation very well. > The need for confidentiality goes away if the client is using a asymmetric > key to authenticate. > > Separately I have been dealing with several OAuth clients (Websites) that > have been compromised and lost all of there OAuth 1 tokens and secrets as > well as all of there Oauth 2 tokens. > We can put it down to bad security, but having long lived access tokens and > there secrets hanging around in databases is a tempting target. > It is also challenging for a client to protect there symmetric client secret > in these cases as it is typically in some file on the disk. > > There may at some point be a push to use asymmetric keys from a HSM to > secure access to the token endpoint and keep the lifetime of the access > tokens short. That's all potential true but symmetric secretes aren't going to just go away so they need to be considered accordingly. > One thing that is a limitation of encoding information in the client_id is > that we don't currently allow the client_id to change during updated in > client registration. > If we did then the JWT could contain some fixed id for the client that the > AS would use as the key for authorizations. Yes, that's pretty much what I was thinking. True, it's a change to registration but registration is still in progress so now is a good time. And the main implication is that clients would need to be able to handle the client_id changing along with other parameters. > I was trying to stay inside the scope of the current drafts. Understood. But I think some kind of life-cycle support for update etc. is needed for this to work beyond just simple set up and test scenarios. So I'd like to consider potential changes to other drafts in order to accommodate. > Our options are to allow client_id to change this requires only a change in > dynamic registration, and not the rest of the client logic, or to crate a > separate parameter for client_assertion that would contain the signed > information including the client_id sending the client_id twice. In a vacuum I think that a separate parameter is a cleaner solution. But with RFC 6749 already out there, I don't think it's particularly viable at this point. > I think allowing the client_id to be reference or assertion as determined > by the AS is more in keeping with what we are doing with access tokens. > I don't think that should require any change to clients, though it would > require change to server logic to treat the incoming client_id as a > reference or assertion to the actual client identifier rather than always > being a literal. Yes but the wire protocol of RFC 6749 is unchanged and I think it's perfectly reasonable to expect an AS that wants stateless clients to make those kinds of changes. > I think it is worth discussing. Thanks, I'll see you in a few hours... > > On Nov 3, 2013, at 8:36 AM, Brian Campbell > wrote: > > Some musings on > http://tools.ietf.org/html/draft-bradley-stateless-oauth-client-00 > > Abstract: "... allowing for fully stateless operation." --> saying that the > statelessness is on the AS side might avoid some confusion. The client is > still going to have to maintain state. > > The kid is header rather than a claim. > > "The issuer SHOULD sign the JWT with JWS ... issuer MAY encrypt the JWT > with JWE." --> this text seems a little off given that the most common case, > I'd think, would be an AS who issues these client id JWTs only for its own > consumption using JWE's AES_CBC_HMAC_SHA2 which gives encryption and > integrity protection. > > Does the relationship between the "iat" and "exp" claims here and the > "client_secret_expires_at" and "client_id_issued_at" parameters of dyn reg > need to be explained or explored more? Strikes me as potentially > problematic. > > And what happens when one of these JWT client ids expires or needs to be > updated? Or the keys used to create or verify them expire? I know the answer > thus far has been that the client will just have to get a new one. But I > feel like that might be too limiting in practice. I'd like to further pursue > understanding/defining how these kinds of client ids might be used in > conjunction with a longer lived way to identify the client that allows the > client id (i.e. the metadata) to change but can allow correlation across > such changes (the sub claim in this doc even suggests that a client might > have such an identifier). > > As was pointed out in another review, there's a difference between > documenting how it's possible for an AS to issue "stateless" client ids for > its own use and defining something that allows for some other party to issue > such ids. It may make sense to discuss them in the same document but I > believe it'd be valuable to have the doc acknowledge and address the > difference more. > > > > > > _______________________________________________ > Openid-specs-ab mailing list > Openid-specs-ab@lists.openid.net > http://lists.openid.net/mailman/listinfo/openid-specs-ab > > From phil.hunt@oracle.com Sun Nov 3 10:42:30 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B9811E8224 for ; Sun, 3 Nov 2013 10:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65PvJ6uixw-v for ; Sun, 3 Nov 2013 10:42:01 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9E321E80BF for ; Sun, 3 Nov 2013 10:41:14 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA3IevjB023968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 3 Nov 2013 18:40:58 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA3Ieu1Z017120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Nov 2013 18:40:57 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA3IeuMV005700; Sun, 3 Nov 2013 18:40:56 GMT Received: from [25.71.163.119] (/24.114.40.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 03 Nov 2013 10:40:55 -0800 References: <5274D238.8070803@gmx.net> <2799AEE6-F443-4591-A3C4-D20258A81AE0@mitre.org> <5276171E.7060307@gmx.net> Mime-Version: 1.0 (1.0) In-Reply-To: <5276171E.7060307@gmx.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9A1B019F-425C-49FC-89B9-CC58617C8A41@oracle.com> X-Mailer: iPhone Mail (11B511) From: Phil Hunt Date: Sun, 3 Nov 2013 10:40:50 -0800 To: Hannes Tschofenig X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Dynamic Client Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 18:42:32 -0000 One other major different is that one starts with token issuance and option r= est for updates if needed. (Dyn assoc).=20 The other is rest centric with token issuance added on as a new mechanism (d= yn reg) Phil > On Nov 3, 2013, at 1:27, Hannes Tschofenig wro= te: >=20 > Thanks for sharing your perspective, Justin. >=20 > This is a good summary of the use cases in the appendix of > draft-richer-oauth-dyn-reg-core-00 and draft-ietf-oauth-dyn-reg-14. The te= xt in the appendix is more focuses on the technical aspects but I believe th= e main difference really is in the user/developer experience in those use ca= ses, which you have summarized in this mail. I > wonder whether it would make sense to include this brief summary of the > use cases in the introduction section of the document (and point to the > more detailed writeup in the appendix). >=20 > Read through the document I have been to find out what the disconnect in > the group has been and my only idea was that it might have something to > do with the focus on different scenarios. If that's not the case then I > really don't know. >=20 > Since I am interested to make some progress on this area I am curious > about what could be done. >=20 > Here is what I believe I see: >=20 > * We have the core specification (with is with > draft-richer-oauth-dyn-reg-core-00 quite stripped down to focus on the > interaction with the registration endpoint) >=20 > * We have the software statements document > , which are a step that happens > before the registration interaction kicks in. I see this as an > independent specification that can easily be run before the steps > outlined in > draft-richer-oauth-dyn-reg-core-00 >=20 > * We have two approaches for managing registration information, namely > draft-richer-oauth-dyn-reg-management and > draft-hunt-oauth-scim-client-reg-00 (whereby the latter uses SCIM as a > baseline and the former doesn't). I understand the argument that someone > who already implements SCIM might as well want to re-use it. Of course, > if you don't use SCIM then that argument does not get you too far. In > that sense, I could imagine both being valid approach (with suitability > for different environments). What I would like to see is how different > they are with their on-the-wire behavior since both are supposed to be > RESTful APIs >=20 > * Finally, there was this worry about the stateless nature of the AS > (with respect to the clients and their client ids). John had produced an > interesting writeup to illustrate that you can accomplish the goal with > the current OAuth 2.0 spec when you construct the client-id in a special > way. >=20 > A path forward could be to >=20 > * go ahead with draft-richer-oauth-dyn-reg-core-00 (with minor updates > to create the link to the other documents, such as the software statement)= . >=20 > * publish the software statement document >=20 > * for the approach of managing registration requires a bit of analysis > to see whether the two approaches are indeed that different. If they are > indeed very different then it might make sense to publish both. However, > if they are not that different then we need to make a decision what we > want to go further with. We don't need two specifications that are > almost identical >=20 > * I also think we should publish > draft-bradley-stateless-oauth-client-00 as an informational document > since it seems to be something that people worry about and the document > illustrates how to accomplish the desired functionality without > normative changes to the OAuth 2.0 protocol. >=20 > Ciao > Hannes >=20 > Am 03.11.13 05:28, schrieb Richer, Justin P.: >> Hannes, >>=20 >> There are a number of major use cases and expectations that I've kept >> in mind throughout the development of this protocol. Some of the >> fallout of this is captured in appendix B of the current draft, but >> I'd be happy to write them out here: >>=20 >>=20 >> First, the use cases of OpenID Connect and UMA are driving factors, >> which shouldn't be surprising since the draft that we have now came >> into existence by combining the UMA dynamic registration draft (which >> started its life over 3 years ago now) and the OpenID Connect dynamic >> registration draft (which is at least 2 years old). In both of these >> cases, the trust starts at the end user, who effectively makes the >> introductions between the different components. For example, in >> Connect's fully open and distributed mode, the end user types in a >> web finger address at the RP to point to an IdP that the RP's >> potentially never heard of. That RP needs to be able to talk to that >> IdP in real time, while the user is still there. Likewise in UMA, the >> end user points the client at the API which discovers the AS. Any >> kind of step that requires a system administrator or developer to be >> involved is a dead stop for the fully distributed cases of these >> protocols, since the whole point is to *automate* the process of >> registration. The case is even more clear with BlueButton+, a >> healthcare data access protocol, where the end user is the patient. >> The patient has the right and ability to connect their health care >> provider's API (protected by the provider's AS) to a client of the >> patient's choosing, even if the provider or the provider's software >> vendor has never heard of the client software before. >>=20 >> That said, there's a "more trusted" middle ground where you get >> authorized to call the registration endpoint, and you can show that >> by presenting an initial access token as part of that request. We've >> taken that mechanism with BlueButton+ and defined our own initial >> access token as a signed JWT assertion presented as a bearer >> assertion. (There's also a discovery protocol in BB+ that defines how >> the AS can validate the assertion.) Large providers, like the Googles >> and Facebooks of the world, like to have a relationship with the >> developer ahead of time. The developer is effectively issued an >> access token to tie their clients back to the developer's account. >> There can be a problem with this though, and it's important to think >> of the dynamic registration from two perspectives: >>=20 >> =46rom the perspective of the AS, the protocol is all about introducing >> new clients. In this view, you've got an AS with lots of different >> client applications trying to talk to it. These might be many copies >> of the same code base, or many different code bases, but each >> instance needs to be able to present a client_id and client_secret >> (or equivalent authentication) that the AS can recognize. In an >> enterprise, it's common to think from this perspective because it's >> usually the enterprise that's rolling out the AS and wanting to >> provide access to a published API to a bunch of clients that may or >> may not be known ahead of time. >>=20 >> =46rom the perspective of the client (which is really to say, an >> instance of a client), the protocol is all about introducing the >> client to a bunch of different auth servers. This is usually the case >> when you've got an "open" API, like OIDC, that may be hosted by any >> number of unknown parties that need to be discovered at runtime. One >> client can talk to a number of different instantiations of this same >> API. This perspective often gets lost when people talk about >> deploying auth servers (especially the large internet providers) or >> having some kind of trusted registration, like what Google wants to >> do with giving developers access tokens. However, I think that this >> perspective is going to become more important as we have more >> widespread common APIs and better service discovery systems. Note >> that in BB+ we have both open and trusted registrations, with the >> open registrations MTI. >>=20 >>=20 >> Extensibility of the base draft is also a very important >> consideration to me. OAuth works because it's a set of composable >> blocks that can be brought together to solve a wide variety of >> problems. As such, it's important that the client's metadata be >> safely and easily extensible so that specific protocols being >> protected by OAuth (like Connect or Blue Button) can easily define >> protocol-specific client aspects. This would also be the logical >> place to inject Phil's proposed software statement, as an extension >> to the client's presented metadata and a means for protecting >> particular fields with a signature. Additionally, since OAuth has >> many different methods of clients authenticating, the draft defines a >> registry to allow for specific OAuth-protected protocols and systems >> to define different auth methods, like Connect's private_key_jwt and >> client_secret_jwt methods that are more specific to how Connect >> defines its interactions. I'm sure there will be other methods in the >> future, too. >>=20 >>=20 >> Finally, the ability of the client to manage the metadata that's >> attached to a client_id over time is important in some use cases. >> Fundamentally, the registration process is the "Create" verb, and the >> "Read/Update/Delete" verbs are a short step after that to implement. >> It's become clear to me that if your authorization servers are fully >> stateless, or if you believe that all of the metadata properties of a >> given client (or even piece of software with multiple instances), >> then the management API doesn't make any sense. However, neither of >> these assumptions are universal, and with the right components, we >> can have a system that can be composed in different ways to fit all >> of these use cases. >>=20 >> -- Justin >>=20 >> On Nov 2, 2013, at 6:21 AM, Hannes Tschofenig >> wrote: >>=20 >>> Hi all, >>>=20 >>> reading througth various dynamic client registration document I get >>> the impression that there is one area of potential disconnect, >>> namely in the end user / developer experience. >>>=20 >>> When OpenID started this concept that a random IdP could talk to a >>> random RP it seemed like a great idea. There was no need to >>> exchange secrets and go through this complicated introduction >>> process between the different parties, which sometimes even >>> required business argeements. Those processes were known from >>> Kerberos and also from the SAML identity federations. >>>=20 >>> OpenID looked at the entire step from a technical point of view in >>> an attempt to exchange the necessary information and then you were >>> done with it. >>>=20 >>> However, there was a bit more to this whole process, namely the >>> entire notion of trust. In particular, there was the problem that >>> the IdP would hand out information (personal data) to RPs only >>> based on the user's consent. Of course, things could go wrong and >>> some RPs misused the data given by the RP. The IdP couldn't really >>> do anything about that since it knew nothing about the developer at >>> the RP or the RP itself. >>>=20 >>> So, how does the IdP ensure that it has some way to improve >>> security and privacy of their users without handing out just >>> everything. Of course, the IdP had it's own interest to know to >>> know data is being passed to. >>>=20 >>> Jumping to OAuth many deployments required developers to register >>> and this registration procedure might require lots of information >>> (such as credit card number, phone number, agreeing the terms of >>> service, etc.). So, in many cases it wasn't purely about giving the >>> developer a client-id and a shared secret for the client >>> application. >>>=20 >>> Now, here is the challenge: there are obviously different >>> environments developers produce software for (such as the Web, the >>> mobile app eco-system, and enterprise environments). They might all >>> have different processes and expectations about the entire >>> process. >>>=20 >>> We have pretty much short-cut the entire story to the purely >>> technical parts, namely to sending messages around and defining new >>> attributes and have done very little in describing the process >>> itself that we assume takes place. >>>=20 >>> I know that you have these processes in your head when you write >>> your documents and in discussions I have heard about these >>> processes. Unfortunately, they aren't really documented anywhere. I >>> guess it is needless to say that the expectations about how >>> enterprises plan to deploy software vs. how the same is done for >>> the Web is somewhat different. >>>=20 >>> So, I believe it is useful to chat about these aspects even though >>> they may just lead to a few paragraphs in our documents providing >>> background information rather than actual normative specification >>> text. >>>=20 >>> Ciao Hannes _______________________________________________ OAuth >>> mailing list OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Sun Nov 3 10:43:28 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B9A21F9DCA for ; Sun, 3 Nov 2013 10:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVBYgA9s9XhO for ; Sun, 3 Nov 2013 10:43:19 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5E711E82E0 for ; Sun, 3 Nov 2013 10:43:11 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA3Ih6VE025392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 3 Nov 2013 18:43:07 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA3Ih6tO019310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Nov 2013 18:43:06 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA3Ih6Qq007942; Sun, 3 Nov 2013 18:43:06 GMT Received: from [25.71.163.119] (/24.114.40.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 03 Nov 2013 10:43:06 -0800 References: <5274D238.8070803@gmx.net> <49AA7409-C574-43E4-8D44-827092B356B2@oracle.com> <52761718.2060808@gmx.net> Mime-Version: 1.0 (1.0) In-Reply-To: <52761718.2060808@gmx.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6E3C063D-C3C0-4801-9C46-D0278C919067@oracle.com> X-Mailer: iPhone Mail (11B511) From: Phil Hunt Date: Sun, 3 Nov 2013 10:43:01 -0800 To: Hannes Tschofenig X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Dynamic Client Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 18:43:28 -0000 +1 agreed. There is lots to negotiate still.=20 Phil > On Nov 3, 2013, at 1:27, Hannes Tschofenig wro= te: >=20 > Hi Phil, >=20 > you are right that I should have used different terminology, such as the c= lassification that Justin uses in his document (such as 'open registration',= 'protected registration') since the term 'enterprise' and 'web' carries a l= ot of other emotions and baggage that is not relevant to this discussion. >=20 > What would be good to ensure is that we capture the different classes. > We have at least the following cases: >=20 > * Out-of-band registration of the developer and the client (as we have it w= ith many deployments of OAuth 2.0 today). >=20 > * Open Registration (where there is no prior interaction between the RP an= d the IdP). >=20 > * Then, there is a mixed case (where I would include your softare statemen= ts) where other information is used for authorizing the client (or client in= stance). >=20 > [The difficulty I had writing these cases while at the same time looking a= t draft-richer-oauth-dyn-reg-core-00 tells me that the major differences bet= ween the different cases are not immediately visible from Appendix B of draf= t-richer-oauth-dyn-reg-core-00 even though there is a lot of text.] >=20 > In some sense you have tried your own version of this classification in th= e software statement document, but as I had noted in my review, I believe yo= u are also not quite there yet. >=20 > Ciao > Hannes >=20 > Am 02.11.13 17:08, schrieb Phil Hunt: >> Hannes, >>=20 >> Some really good, thought provoking comments! I had not really been >> focused as much on financial relationships between SP and client. I >> must confess I considered web clients that set up major relations >> with service providers. In these cases I dismissed them as a use case >> because they would most likely configure manually and actually end up >> in the "static" class of clients. Still, I think we should give this >> some more careful thought. >>=20 >> What were you thinking of as a "enterprise" that differentiates with >> what we are currently talking about? Enterprise these days has so >> much derogatory baggage that it is hard to tell what is being >> referred to. >>=20 >> There is a quality of APIs that 6749 focuses on that registration can >> fix. 6749 works well for "monopoly"/"singleton" API providers like >> Google, Facebook, etc. Yet there are lots of "open" APIs established >> through open source projects, open standards (e.g. Connect), and >> commercial cases where customers will deploy their own copies of an >> API. I'm not sure this really is "enterprise". Even in the >> commercial cases, these APIs are most often made available as "open" >> for use by third party developers. For me, this isn't a case of >> extending OAuth to support "enterprise", but rather extending OAuth >> to support "open" or "multiple-deployment" APIs on the web no matter >> where or how they are deployed. >>=20 >> Phil >>=20 >> @independentid www.independentid.com phil.hunt@oracle.com >>=20 >> On 2013-11-02, at 3:21 AM, Hannes Tschofenig >> wrote: >>=20 >>> Hi all, >>>=20 >>> reading througth various dynamic client registration document I get >>> the impression that there is one area of potential disconnect, >>> namely in the end user / developer experience. >>>=20 >>> When OpenID started this concept that a random IdP could talk to a >>> random RP it seemed like a great idea. There was no need to >>> exchange secrets and go through this complicated introduction >>> process between the different parties, which sometimes even >>> required business argeements. Those processes were known from >>> Kerberos and also from the SAML identity federations. >>>=20 >>> OpenID looked at the entire step from a technical point of view in >>> an attempt to exchange the necessary information and then you were >>> done with it. >>>=20 >>> However, there was a bit more to this whole process, namely the >>> entire notion of trust. In particular, there was the problem that >>> the IdP would hand out information (personal data) to RPs only >>> based on the user's consent. Of course, things could go wrong and >>> some RPs misused the data given by the RP. The IdP couldn't really >>> do anything about that since it knew nothing about the developer at >>> the RP or the RP itself. >>>=20 >>> So, how does the IdP ensure that it has some way to improve >>> security and privacy of their users without handing out just >>> everything. Of course, the IdP had it's own interest to know to >>> know data is being passed to. >>>=20 >>> Jumping to OAuth many deployments required developers to register >>> and this registration procedure might require lots of information >>> (such as credit card number, phone number, agreeing the terms of >>> service, etc.). So, in many cases it wasn't purely about giving the >>> developer a client-id and a shared secret for the client >>> application. >>>=20 >>> Now, here is the challenge: there are obviously different >>> environments developers produce software for (such as the Web, the >>> mobile app eco-system, and enterprise environments). They might all >>> have different processes and expectations about the entire >>> process. >>>=20 >>> We have pretty much short-cut the entire story to the purely >>> technical parts, namely to sending messages around and defining new >>> attributes and have done very little in describing the process >>> itself that we assume takes place. >>>=20 >>> I know that you have these processes in your head when you write >>> your documents and in discussions I have heard about these >>> processes. Unfortunately, they aren't really documented anywhere. I >>> guess it is needless to say that the expectations about how >>> enterprises plan to deploy software vs. how the same is done for >>> the Web is somewhat different. >>>=20 >>> So, I believe it is useful to chat about these aspects even though >>> they may just lead to a few paragraphs in our documents providing >>> background information rather than actual normative specification >>> text. >>>=20 >>> Ciao Hannes _______________________________________________ OAuth >>> mailing list OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 From jricher@mitre.org Sun Nov 3 13:42:28 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185B421E80BD for ; Sun, 3 Nov 2013 13:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.422 X-Spam-Level: X-Spam-Status: No, score=-6.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtvDSmoboWHl for ; Sun, 3 Nov 2013 13:42:23 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0A19711E8123 for ; Sun, 3 Nov 2013 13:42:23 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6FB201F0323; Sun, 3 Nov 2013 16:42:22 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B12391F029C; Sun, 3 Nov 2013 16:42:21 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.251]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.03.0158.001; Sun, 3 Nov 2013 16:42:21 -0500 From: "Richer, Justin P." To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] Dynamic Client Registration Thread-Index: AQHO17VpgVm3wOfIFkiR4ENfx3W3lg== Date: Sun, 3 Nov 2013 21:42:20 +0000 Message-ID: References: <5274D238.8070803@gmx.net> <2799AEE6-F443-4591-A3C4-D20258A81AE0@mitre.org> <5276171E.7060307@gmx.net> In-Reply-To: <5276171E.7060307@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.40.172] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Dynamic Client Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 21:42:28 -0000 Hannes, I think that your proposed path forward is reasonable, and it fits with the= mentality I've always held that we can build this with reusable blocks to = fit many different use cases.=20 For what it's worth, I think that if people want a SCIM-based management pr= ofile then it should be published and handled in the SCIM working group so = that it can track with the SCIM spec (which is still changing). In my opini= on, there is plenty of value of having a non-SCIM RESTful API for everyone = who wants to manage the objects but not implement all of SCIM. We can defin= e that API here. -- Justin On Nov 3, 2013, at 1:27 AM, Hannes Tschofenig w= rote: > Thanks for sharing your perspective, Justin. >=20 > This is a good summary of the use cases in the appendix of > draft-richer-oauth-dyn-reg-core-00 and draft-ietf-oauth-dyn-reg-14. The t= ext in the appendix is more focuses on the technical aspects but I believe = the main difference really is in the user/developer experience in those use= cases, which you have summarized in this mail. I > wonder whether it would make sense to include this brief summary of the > use cases in the introduction section of the document (and point to the > more detailed writeup in the appendix). >=20 > Read through the document I have been to find out what the disconnect in > the group has been and my only idea was that it might have something to > do with the focus on different scenarios. If that's not the case then I > really don't know. >=20 > Since I am interested to make some progress on this area I am curious > about what could be done. >=20 > Here is what I believe I see: >=20 > * We have the core specification (with is with > draft-richer-oauth-dyn-reg-core-00 quite stripped down to focus on the > interaction with the registration endpoint) >=20 > * We have the software statements document > , which are a step that happens > before the registration interaction kicks in. I see this as an > independent specification that can easily be run before the steps > outlined in > draft-richer-oauth-dyn-reg-core-00 >=20 > * We have two approaches for managing registration information, namely > draft-richer-oauth-dyn-reg-management and > draft-hunt-oauth-scim-client-reg-00 (whereby the latter uses SCIM as a > baseline and the former doesn't). I understand the argument that someone > who already implements SCIM might as well want to re-use it. Of course, > if you don't use SCIM then that argument does not get you too far. In > that sense, I could imagine both being valid approach (with suitability > for different environments). What I would like to see is how different > they are with their on-the-wire behavior since both are supposed to be > RESTful APIs >=20 > * Finally, there was this worry about the stateless nature of the AS > (with respect to the clients and their client ids). John had produced an > interesting writeup to illustrate that you can accomplish the goal with > the current OAuth 2.0 spec when you construct the client-id in a special > way. >=20 > A path forward could be to >=20 > * go ahead with draft-richer-oauth-dyn-reg-core-00 (with minor updates > to create the link to the other documents, such as the software statement= ). >=20 > * publish the software statement document >=20 > * for the approach of managing registration requires a bit of analysis > to see whether the two approaches are indeed that different. If they are > indeed very different then it might make sense to publish both. However, > if they are not that different then we need to make a decision what we > want to go further with. We don't need two specifications that are > almost identical >=20 > * I also think we should publish > draft-bradley-stateless-oauth-client-00 as an informational document > since it seems to be something that people worry about and the document > illustrates how to accomplish the desired functionality without > normative changes to the OAuth 2.0 protocol. >=20 > Ciao > Hannes >=20 > Am 03.11.13 05:28, schrieb Richer, Justin P.: >> Hannes, >>=20 >> There are a number of major use cases and expectations that I've kept >> in mind throughout the development of this protocol. Some of the >> fallout of this is captured in appendix B of the current draft, but >> I'd be happy to write them out here: >>=20 >>=20 >> First, the use cases of OpenID Connect and UMA are driving factors, >> which shouldn't be surprising since the draft that we have now came >> into existence by combining the UMA dynamic registration draft (which >> started its life over 3 years ago now) and the OpenID Connect dynamic >> registration draft (which is at least 2 years old). In both of these >> cases, the trust starts at the end user, who effectively makes the >> introductions between the different components. For example, in >> Connect's fully open and distributed mode, the end user types in a >> web finger address at the RP to point to an IdP that the RP's >> potentially never heard of. That RP needs to be able to talk to that >> IdP in real time, while the user is still there. Likewise in UMA, the >> end user points the client at the API which discovers the AS. Any >> kind of step that requires a system administrator or developer to be >> involved is a dead stop for the fully distributed cases of these >> protocols, since the whole point is to *automate* the process of >> registration. The case is even more clear with BlueButton+, a >> healthcare data access protocol, where the end user is the patient. >> The patient has the right and ability to connect their health care >> provider's API (protected by the provider's AS) to a client of the >> patient's choosing, even if the provider or the provider's software >> vendor has never heard of the client software before. >>=20 >> That said, there's a "more trusted" middle ground where you get >> authorized to call the registration endpoint, and you can show that >> by presenting an initial access token as part of that request. We've >> taken that mechanism with BlueButton+ and defined our own initial >> access token as a signed JWT assertion presented as a bearer >> assertion. (There's also a discovery protocol in BB+ that defines how >> the AS can validate the assertion.) Large providers, like the Googles >> and Facebooks of the world, like to have a relationship with the >> developer ahead of time. The developer is effectively issued an >> access token to tie their clients back to the developer's account. >> There can be a problem with this though, and it's important to think >> of the dynamic registration from two perspectives: >>=20 >> From the perspective of the AS, the protocol is all about introducing >> new clients. In this view, you've got an AS with lots of different >> client applications trying to talk to it. These might be many copies >> of the same code base, or many different code bases, but each >> instance needs to be able to present a client_id and client_secret >> (or equivalent authentication) that the AS can recognize. In an >> enterprise, it's common to think from this perspective because it's >> usually the enterprise that's rolling out the AS and wanting to >> provide access to a published API to a bunch of clients that may or >> may not be known ahead of time. >>=20 >> From the perspective of the client (which is really to say, an >> instance of a client), the protocol is all about introducing the >> client to a bunch of different auth servers. This is usually the case >> when you've got an "open" API, like OIDC, that may be hosted by any >> number of unknown parties that need to be discovered at runtime. One >> client can talk to a number of different instantiations of this same >> API. This perspective often gets lost when people talk about >> deploying auth servers (especially the large internet providers) or >> having some kind of trusted registration, like what Google wants to >> do with giving developers access tokens. However, I think that this >> perspective is going to become more important as we have more >> widespread common APIs and better service discovery systems. Note >> that in BB+ we have both open and trusted registrations, with the >> open registrations MTI. >>=20 >>=20 >> Extensibility of the base draft is also a very important >> consideration to me. OAuth works because it's a set of composable >> blocks that can be brought together to solve a wide variety of >> problems. As such, it's important that the client's metadata be >> safely and easily extensible so that specific protocols being >> protected by OAuth (like Connect or Blue Button) can easily define >> protocol-specific client aspects. This would also be the logical >> place to inject Phil's proposed software statement, as an extension >> to the client's presented metadata and a means for protecting >> particular fields with a signature. Additionally, since OAuth has >> many different methods of clients authenticating, the draft defines a >> registry to allow for specific OAuth-protected protocols and systems >> to define different auth methods, like Connect's private_key_jwt and >> client_secret_jwt methods that are more specific to how Connect >> defines its interactions. I'm sure there will be other methods in the >> future, too. >>=20 >>=20 >> Finally, the ability of the client to manage the metadata that's >> attached to a client_id over time is important in some use cases. >> Fundamentally, the registration process is the "Create" verb, and the >> "Read/Update/Delete" verbs are a short step after that to implement. >> It's become clear to me that if your authorization servers are fully >> stateless, or if you believe that all of the metadata properties of a >> given client (or even piece of software with multiple instances), >> then the management API doesn't make any sense. However, neither of >> these assumptions are universal, and with the right components, we >> can have a system that can be composed in different ways to fit all >> of these use cases. >>=20 >> -- Justin >>=20 >> On Nov 2, 2013, at 6:21 AM, Hannes Tschofenig >> wrote: >>=20 >>> Hi all, >>>=20 >>> reading througth various dynamic client registration document I get >>> the impression that there is one area of potential disconnect, >>> namely in the end user / developer experience. >>>=20 >>> When OpenID started this concept that a random IdP could talk to a >>> random RP it seemed like a great idea. There was no need to >>> exchange secrets and go through this complicated introduction >>> process between the different parties, which sometimes even >>> required business argeements. Those processes were known from >>> Kerberos and also from the SAML identity federations. >>>=20 >>> OpenID looked at the entire step from a technical point of view in >>> an attempt to exchange the necessary information and then you were >>> done with it. >>>=20 >>> However, there was a bit more to this whole process, namely the >>> entire notion of trust. In particular, there was the problem that >>> the IdP would hand out information (personal data) to RPs only >>> based on the user's consent. Of course, things could go wrong and >>> some RPs misused the data given by the RP. The IdP couldn't really >>> do anything about that since it knew nothing about the developer at >>> the RP or the RP itself. >>>=20 >>> So, how does the IdP ensure that it has some way to improve >>> security and privacy of their users without handing out just >>> everything. Of course, the IdP had it's own interest to know to >>> know data is being passed to. >>>=20 >>> Jumping to OAuth many deployments required developers to register >>> and this registration procedure might require lots of information >>> (such as credit card number, phone number, agreeing the terms of >>> service, etc.). So, in many cases it wasn't purely about giving the >>> developer a client-id and a shared secret for the client >>> application. >>>=20 >>> Now, here is the challenge: there are obviously different >>> environments developers produce software for (such as the Web, the >>> mobile app eco-system, and enterprise environments). They might all >>> have different processes and expectations about the entire >>> process. >>>=20 >>> We have pretty much short-cut the entire story to the purely >>> technical parts, namely to sending messages around and defining new >>> attributes and have done very little in describing the process >>> itself that we assume takes place. >>>=20 >>> I know that you have these processes in your head when you write >>> your documents and in discussions I have heard about these >>> processes. Unfortunately, they aren't really documented anywhere. I >>> guess it is needless to say that the expectations about how >>> enterprises plan to deploy software vs. how the same is done for >>> the Web is somewhat different. >>>=20 >>> So, I believe it is useful to chat about these aspects even though >>> they may just lead to a few paragraphs in our documents providing >>> background information rather than actual normative specification >>> text. >>>=20 >>> Ciao Hannes _______________________________________________ OAuth >>> mailing list OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 From Michael.Jones@microsoft.com Sun Nov 3 22:52:56 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322FF21E8142 for ; Sun, 3 Nov 2013 22:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.484 X-Spam-Level: X-Spam-Status: No, score=-3.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdWGb4GQdj+J for ; Sun, 3 Nov 2013 22:52:51 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0149.outbound.protection.outlook.com [207.46.163.149]) by ietfa.amsl.com (Postfix) with ESMTP id C9FEE11E819D for ; Sun, 3 Nov 2013 22:52:47 -0800 (PST) Received: from BL2PR03CA021.namprd03.prod.outlook.com (10.141.66.29) by BL2PR03MB162.namprd03.prod.outlook.com (10.255.230.145) with Microsoft SMTP Server (TLS) id 15.0.815.6; Mon, 4 Nov 2013 06:52:43 +0000 Received: from BN1BFFO11FD021.protection.gbl (2a01:111:f400:7c10::138) by BL2PR03CA021.outlook.office365.com (2a01:111:e400:c1b::29) with Microsoft SMTP Server (TLS) id 15.0.815.6 via Frontend Transport; Mon, 4 Nov 2013 06:52:43 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD021.mail.protection.outlook.com (10.58.53.81) with Microsoft SMTP Server (TLS) id 15.0.815.5 via Frontend Transport; Mon, 4 Nov 2013 06:52:43 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.160]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0158.002; Mon, 4 Nov 2013 06:52:02 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: New Version Notification for draft-jones-oauth-token-exchange-00.txt Thread-Index: AQHO2Sk0Ot9KsFF890GZpKuV3FQp3ZoUoF8g Date: Mon, 4 Nov 2013 06:52:01 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394377E399A3@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <20131104064317.10172.86977.idtracker@ietfa.amsl.com> In-Reply-To: <20131104064317.10172.86977.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377424004)(377454003)(199002)(189002)(13464003)(55846006)(47736001)(49866001)(4396001)(50986001)(47976001)(33656001)(66066001)(65816001)(80022001)(77982001)(59766001)(79102001)(63696002)(47776003)(20776003)(54316002)(56776001)(77096001)(56816003)(46102001)(19580405001)(83322001)(44976005)(51856001)(19580395003)(69226001)(6806004)(76786001)(76796001)(81342001)(81542001)(47446002)(74502001)(31966008)(74662001)(85306002)(23676002)(54356001)(81816001)(81686001)(53806001)(80976001)(15975445006)(74706001)(74876001)(83072001)(2656002)(87266001)(15202345003)(50466002)(76482001)(74366001)(6606295002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB162; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0020414413 X-OriginatorOrg: microsoft.com Subject: [OAUTH-WG] FW: New Version Notification for draft-jones-oauth-token-exchange-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 06:52:56 -0000 V2UnbGwgZGlzY3VzcyB0aGlzIHRvbW9ycm93LiAgSSd2ZSBhbHNvIHBvc3RlZCBhbiBIVE1MIHZl cnNpb24gYXQgaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1qb25lcy1vYXV0aC10 b2tlbi1leGNoYW5nZS0wMC5odG1sLg0KDQoJCQkJLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFN1bmRheSwgTm92ZW1iZXIgMDMsIDIwMTMgMTA6 NDMgUE0NClRvOiBNaWtlIEpvbmVzOyBNaWtlIEpvbmVzDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWpvbmVzLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAwLnR4dA0K DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1qb25lcy1vYXV0aC10b2tlbi1leGNoYW5n ZS0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWljaGFlbCBCLiBK b25lcyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJh ZnQtam9uZXMtb2F1dGgtdG9rZW4tZXhjaGFuZ2UNClJldmlzaW9uOgkgMDANClRpdGxlOgkJIE9B dXRoIDIuMCBUb2tlbiBFeGNoYW5nZQ0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMTEtMDMNCkdyb3Vw OgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA5DQpVUkw6ICAgICAg ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWpvbmVzLW9h dXRoLXRva2VuLWV4Y2hhbmdlLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWpvbmVzLW9hdXRoLXRva2VuLWV4Y2hhbmdlDQpIdG1s aXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLW9hdXRo LXRva2VuLWV4Y2hhbmdlLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIHNwZWNpZmljYXRpb24g ZGVmaW5lcyBob3cgdG8gcmVxdWVzdCBhbmQgb2J0YWluIFNlY3VyaXR5IFRva2Vucw0KICAgZnJv bSBPQXV0aCBBdXRob3JpemF0aW9uIFNlcnZlcnMsIGluY2x1ZGluZyBlbmFibGluZyBvbmUgcGFy dHkgdG8gYWN0DQogICBvbiBiZWhhbGYgb2YgYW5vdGhlciBvciBlbmFibGluZyBvbmUgcGFydHkg dG8gZGVsZWdhdGUgYXV0aG9yaXR5IHRvDQogICBhbm90aGVyLg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVU RiBTZWNyZXRhcmlhdA0KDQo= From wwwrun@rfc-editor.org Mon Nov 4 08:20:42 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557CF21F9D7A for ; Mon, 4 Nov 2013 08:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wgn7j03o7002 for ; Mon, 4 Nov 2013 08:20:41 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 597E511E81E1 for ; Mon, 4 Nov 2013 08:20:24 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id E102975E012; Mon, 4 Nov 2013 08:10:54 -0800 (PST) To: dick.hardt@gmail.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, Hannes.Tschofenig@gmx.net, derek@ihtfp.com From: RFC Errata System Message-Id: <20131104161054.E102975E012@rfc-editor.org> Date: Mon, 4 Nov 2013 08:10:54 -0800 (PST) Cc: oauth@ietf.org, rfc-editor@rfc-editor.org Subject: [OAUTH-WG] [Technical Errata Reported] RFC6749 (3780) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 16:20:42 -0000 The following errata report has been submitted for RFC6749, "The OAuth 2.0 Authorization Framework". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3780 -------------------------------------- Type: Technical Reported by: Torsten Lodderstedt Section: 3.2.1 Original Text ------------- A client MAY use the "client_id" request parameter to identify itself when sending requests to the token endpoint. Corrected Text -------------- A public client MAY use the "client_id" request parameter to identify itself when sending requests to the token endpoint. Notes ----- The current text may mislead confidential clients to sent their client_id in the request body in addition to their client_id and client_secret in the BASIC authz header. This leads to unnecessary duplication and ambiguities. There has been consensus on the list that the intention of this sentence was to advise _public_ clients to identity themselves towards the token endpoint in order to mitigate substitution attacks and allow for logging. Confidential clients need to authenticate anyway, this sentence should be narrowed down to public clients only. see http://www.ietf.org/mail-archive/web/oauth/current/msg12005.html This issue was discovered in the course of the OpenID Connect Interop testings. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6749 (draft-ietf-oauth-v2-31) -------------------------------------- Title : The OAuth 2.0 Authorization Framework Publication Date : October 2012 Author(s) : D. Hardt, Ed. Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From bcampbell@pingidentity.com Mon Nov 4 10:25:33 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4104821E8240 for ; Mon, 4 Nov 2013 10:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.89 X-Spam-Level: X-Spam-Status: No, score=-5.89 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9OAGfvg-77n for ; Mon, 4 Nov 2013 10:25:28 -0800 (PST) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6CE21E817E for ; Mon, 4 Nov 2013 10:25:24 -0800 (PST) Received: from mail-ie0-f170.google.com ([209.85.223.170]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKUnfmi3vmzmnXg5o5b4M8cGoHMyzqSyvR@postini.com; Mon, 04 Nov 2013 10:25:24 PST Received: by mail-ie0-f170.google.com with SMTP id at1so13394569iec.29 for ; Mon, 04 Nov 2013 10:24:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ySBvfhYjB8uJYN6kwTSmIfyDI6lY6tmb+YE5lrpIICA=; b=e+fcGyTlJfXn+C6miAvAnNjPyUyu6XrUJyXiOkldK+U1Q8+QLoPlXfvjKH18ehQWOd l/TljL5jpgyFSQXUZ72pxfrmJsXvflXMW/kCek3ePe4OPVnHEGcrrIWjEmfEvMogz65y vAmAOT9i8cC85tc8x5gfu2Pn3BwMP1FpUw9LcjWEUi+bIPJmxVdRA6Fqr8OhbbQHY+eZ DhThZfF8EW5EfC3MOEcGSBQYel+9/2/e70J0ZC8Omh4TTT0KGX+rYd/LjAVNDifzXtb5 C/ggkyj70VUP0goGHZ3QG0WA1d86njL6DcPtedOCD0dJYD5NvIy6bDKQMlSaigSj/PrK bwzA== X-Gm-Message-State: ALoCoQl1mMBGaAqx6UtHEXQ2U896q9CCecmZamI9uyt/qAfNzZfoVseRXHOm2fMlcEO5DFELej+kJONn6VlHEN+/b/2ehAYj8Z6XTR3bxrv9tzXrIt2lDah7W9sntbFAntp4ruzKt73zkZy3Z0FbnGXoDvtCsGw0HA== X-Received: by 10.50.110.74 with SMTP id hy10mr12989360igb.0.1383589493553; Mon, 04 Nov 2013 10:24:53 -0800 (PST) X-Received: by 10.50.110.74 with SMTP id hy10mr12989355igb.0.1383589493472; Mon, 04 Nov 2013 10:24:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.245.233 with HTTP; Mon, 4 Nov 2013 10:24:23 -0800 (PST) In-Reply-To: <52741472.8020405@gmx.net> References: <52741472.8020405@gmx.net> From: Brian Campbell Date: Mon, 4 Nov 2013 10:24:23 -0800 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 18:25:33 -0000 Thanks for the review and feedback Hannes. There are a number of different items here and I think it'll be more productive to discuss them individually, so I'll partition this into a different threads for each general topic. I plan to do the same thing for your review of draft-ietf-oauth-saml2-bearer-17 from http://www.ietf.org/mail-archive/web/oauth/current/msg12230.html On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig wrote: > Hi Mike, Hi all, > > I read through draft-ietf-oauth-jwt-bearer-06 in an attempt to find out > whether I would be able to produce an interoperable implementation from this > document. > > A few minor things came to my mind: > > Section 3: > > You write: > " > 1. The JWT MUST contain an "iss" (issuer) claim that contains a > unique identifier for the entity that issued the JWT. Issuer > values SHOULD be compared using the Simple String Comparison > method defined in Section 6.2.1 of RFC 3986 [RFC3986], unless > otherwise specified by the application. > " > > What is not stated here is what are the two values that are compared against > each other. One value is the issuer claim from the JWT and the other value > is the, I guess, an entry from a whitelist of trusted issuers. > > > > You write: > " > 2. The JWT MUST contain a "sub" (subject) claim identifying the > subject of the transaction. The subject MAY identify the > resource owner for whom the access token is being requested. > > A. When using a JWT as an authorization grant, the subject > SHOULD identify an authorized accessor for whom the access > token is being requested (typically the resource owner, or > an authorized delegate). > > B. For client authentication, the subject MUST be the > "client_id" of the OAuth client. > " > > Should this rather read: > > " > 2. The JWT MUST contain a "sub" (subject) claim identifing the > principal that is the subject of the JWT. Two cases need to > be differentiated: > > A. For the authorization grant, the subject > SHOULD identify an authorized accessor for whom the access > token is being requested (typically the resource owner, or > an authorized delegate). > > B. For client authentication, the subject MUST be the > "client_id" of the OAuth client. > " > > Why isn't the SHOULD under (A) actually a MUST? Then, the current text in A > is so fuzzy that it actually doesn't allow someone to create a test case to > test whether an implementation is interoperable or not. With B the situation > is different. Is there something else we can say for A? > > You write: > > " > 3. The JWT MUST contain an "aud" (audience) claim containing a > value that identifies the authorization server as an intended > audience. The token endpoint URL of the authorization server > MAY be used as a value for an "aud" element to identify the > authorization server as an intended audience of the JWT. JWTs > that do not identify the authorization server as an intended > audience MUST be rejected. Audience values SHOULD be compared > using the Simple String Comparison method defined in Section > 6.2.1 of RFC 3986 [RFC3986], unless otherwise specified by the > application. > " > > If the endpoint URL of the AS is not used then what else? Wouldn't it be > useful to say "The token endpoint URL of the authorization server > MUST be used as a value for an "aud" element to identify the > authorization server as an intended audience of the JWT."? > > Then, I have a suggestion for re-phrasing this sentence from : > " > Audience values SHOULD be compared > using the Simple String Comparison method defined in Section > 6.2.1 of RFC 3986 [RFC3986], unless otherwise specified by the > application. > " > to: > > " > In the absence of an application profile standard specifying > otherwise, a compliant JWT Bearer application MUST compare the audience > values using the Simple String Comparison method defined in Section > 6.2.1 of RFC 3986 [RFC3986]. > " > > The same can actually be applied to the issuer claim as well. > Given that the JWT had been updated to align it with the JOSE work I suspect > that this document also requires an update. > > > Section 5 about "Interoperability Considerations" says: > > " > Specific items that require agreement are as > follows: values for the issuer and audience identifiers, the location > of the token endpoint, and the key used to apply and verify the > digital signature or keyed message digest over the JWT. > " > > I believe that this list is not correct. > > What is needed is: > > * At the authorization server there needs to be a whitelist of trusted > issuers. For a succesful protocol run the JWT needs to be created by an > issuer who is in the whitelist. > > * Along with the entry in the whitelist of trusted issuers needs to be a > key. > > There is no new endpoint URL defined by this document. As such, I wouldn't > mention those. > > I also do not think that the audience identifier needs to be agreed if you > define it as the token endpoint URL of the authorization server (as I > suggested above). > > Ciao > Hannes > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From bcampbell@pingidentity.com Mon Nov 4 10:44:03 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DA011E81BC for ; Mon, 4 Nov 2013 10:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1LTduTji0Bb for ; Mon, 4 Nov 2013 10:43:56 -0800 (PST) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by ietfa.amsl.com (Postfix) with ESMTP id EB4C911E81CE for ; Mon, 4 Nov 2013 10:43:52 -0800 (PST) Received: from mail-ie0-f172.google.com ([209.85.223.172]) (using TLSv1) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKUnfq5ro4GxEu6I6hXWt0WM4A8e/BCkhL@postini.com; Mon, 04 Nov 2013 10:43:53 PST Received: by mail-ie0-f172.google.com with SMTP id tp5so13379448ieb.3 for ; Mon, 04 Nov 2013 10:43:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=oRNclp3nbG405y1BkDkmhFEyydj1YKriIyD9fO0AkAk=; b=KdEZQpo1ady0fO9Fr4gEDcM6QaXNMdwbwv8On4Vc054hR8jyg5NwbGbWuG4Ge7ZNJn r6+4HADu3ctB6EbNadJfqmUJzlvFWpn+IKFc6RwbRyJa+BbZ1sIfLcWRXaYGhN/9k5tR nW3ZiSi16Pm8VjmKP65UYECt09lSOc4fEEu7rH5KjbhjXVScRWE8fj75NJbd6XGxDzv2 csO3BMRN+uzm7WL4//H6Svxx9qmbOIZJL5yxfDVOwr7ir+NisyqAE/b6EHIVJlDnkZ7C BRJv06YAciItryu16IrVwTU5a3RjwmAaYqFyvcX56EnEgHnromuCclYX8JdYgEB0LQPO +mwg== X-Gm-Message-State: ALoCoQlrCJviL19jNeIyD8AjhY0Hjt0ya7uNL+GjO7oXMnDdD6vZkqIfeUR/7Xsxo4QyRdcXKyY3RwNsjtl9JBoUJansQMhYt0M40sxt4FW2XzDTEJm8E7GJe4mFalMV5PkBLHOpKI22jFbWmjhHgiYgZ1BeV/ohrA== X-Received: by 10.42.126.18 with SMTP id c18mr2012905ics.46.1383590629015; Mon, 04 Nov 2013 10:43:49 -0800 (PST) X-Received: by 10.42.126.18 with SMTP id c18mr2012902ics.46.1383590628918; Mon, 04 Nov 2013 10:43:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.245.233 with HTTP; Mon, 4 Nov 2013 10:43:18 -0800 (PST) From: Brian Campbell Date: Mon, 4 Nov 2013 10:43:18 -0800 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org WG" Subject: [OAUTH-WG] issuer (was draft-ietf-oauth-jwt-bearer-06) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 18:44:03 -0000 On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig wrote: > > Section 3: > > You write: > " > 1. The JWT MUST contain an "iss" (issuer) claim that contains a > unique identifier for the entity that issued the JWT. Issuer > values SHOULD be compared using the Simple String Comparison > method defined in Section 6.2.1 of RFC 3986 [RFC3986], unless > otherwise specified by the application. > " > > What is not stated here is what are the two values that are compared against > each other. One value is the issuer claim from the JWT and the other value > is the, I guess, an entry from a whitelist of trusted issuers. Yes, typically the issuer value is used to lookup policy or configuration data in order to process the transaction. But that is an implementation choice and certainly not the only way it could be done. I've always thought that talking about comparing issuer values is somewhat misleading. Can that second sentence be omitted? Or is there a better way to convey what is intended here? Which is, I think, that even though issuer may be a URI, it should simply be treated as a case sensitive string? From bcampbell@pingidentity.com Mon Nov 4 10:45:07 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1069F21E8160 for ; Mon, 4 Nov 2013 10:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.906 X-Spam-Level: X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpMfSwxIUPAi for ; Mon, 4 Nov 2013 10:45:01 -0800 (PST) Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) by ietfa.amsl.com (Postfix) with ESMTP id BDD4221E805F for ; Mon, 4 Nov 2013 10:44:51 -0800 (PST) Received: from mail-ie0-f179.google.com ([209.85.223.179]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP ID DSNKUnfrI95ICp6RAVwWhQI7B98QvaPaCXqp@postini.com; Mon, 04 Nov 2013 10:44:51 PST Received: by mail-ie0-f179.google.com with SMTP id aq17so12622180iec.24 for ; Mon, 04 Nov 2013 10:44:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=OCal8ubfNAorHoprbEgrVqNMjjcNmcxJYzyWxcyvgzY=; b=YZQ91DCWEaKZE3K+GHBAp5Ep3sY+tqjdjrjIgh3DY312+uPU4S7zoRQcTI96GQyDtr ga/iB2AIPbLLRkDtLk3VpaqOw1H2oSaxnHjDGGWaR7JWYKHzdMKsEpWUtS6JwQ4eAN9i C6g9hl5/MDls8U1wgsVjdwqAkRmnOApyiV2FtahDw49u7rGBRfAMDPXZuM6WS+5G8hCU XFhiPfJSmQsLnM7KwDqeRV7Z/uzCICg2RaEKwNOTVJVjxEU2HUTrEqXn6rU7h+ln1bZo +8LVDNuULK7p6VUlnZFAHJGkvGE8UZNn+1cHhGTUlWThW6p3EOYrX5yu1BcZ/cnrp731 KeDA== X-Gm-Message-State: ALoCoQlNDY5sfTQMp2c66coQ4gOvkuhmNn+jiL/lGF1b7+SO8OV2k3uldeiJom4XMfgrEC9c1le1K/E0b8y1wbnumYh+QNXtn3WGmkBMVfPFxO4ZgcDWYctqK6TeciTZC+PkNgbIdasK1Y1GNy1VHkop6vS2ERcuLA== X-Received: by 10.43.180.200 with SMTP id pf8mr1680959icc.50.1383590691300; Mon, 04 Nov 2013 10:44:51 -0800 (PST) X-Received: by 10.43.180.200 with SMTP id pf8mr1680953icc.50.1383590691229; Mon, 04 Nov 2013 10:44:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.245.233 with HTTP; Mon, 4 Nov 2013 10:44:21 -0800 (PST) From: Brian Campbell Date: Mon, 4 Nov 2013 10:44:21 -0800 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org WG" Subject: [OAUTH-WG] subject (was draft-ietf-oauth-jwt-bearer-06) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 18:45:07 -0000 On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig wrote: > You write: > " > 2. The JWT MUST contain a "sub" (subject) claim identifying the > subject of the transaction. The subject MAY identify the > resource owner for whom the access token is being requested. > > A. When using a JWT as an authorization grant, the subject > SHOULD identify an authorized accessor for whom the access > token is being requested (typically the resource owner, or > an authorized delegate). > > B. For client authentication, the subject MUST be the > "client_id" of the OAuth client. > " > > Should this rather read: > > " > 2. The JWT MUST contain a "sub" (subject) claim identifing the > principal that is the subject of the JWT. Two cases need to > be differentiated: > > A. For the authorization grant, the subject > SHOULD identify an authorized accessor for whom the access > token is being requested (typically the resource owner, or > an authorized delegate). > > B. For client authentication, the subject MUST be the > "client_id" of the OAuth client. > " Agreed that reads better. > Why isn't the SHOULD under (A) actually a MUST? Then, the current text in A > is so fuzzy that it actually doesn't allow someone to create a test case to > test whether an implementation is interoperable or not. With B the situation > is different. Is there something else we can say for A? The fuzziness of the text in A, I believe, comes from use cases where the principal wouldn't directly be identified in the sub claim. For example, a JWT with an anonymous subject and a claim stating they are a member of a particular group might be sufficient to grant access to some types of resources (this is discussed in http://tools.ietf.org/html/draft-ietf-oauth-assertions-12#section-6.3.1). It is also not uncommon, in this federated scenarios, for additional claims/attributes to be needed along with the subject in order to uniquely identify the principle as known to the AS. Is there a way to rephrase the text for A which would be more helpful but not preclude such use cases? From bcampbell@pingidentity.com Mon Nov 4 10:46:11 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A846B21E8153 for ; Mon, 4 Nov 2013 10:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.912 X-Spam-Level: X-Spam-Status: No, score=-5.912 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1qmGdclBYYN for ; Mon, 4 Nov 2013 10:46:04 -0800 (PST) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with ESMTP id 494BB21E805F for ; Mon, 4 Nov 2013 10:45:54 -0800 (PST) Received: from mail-ie0-f177.google.com ([209.85.223.177]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKUnfrYclf5oGs4vhAj2/E4WNqtzlCrZmY@postini.com; Mon, 04 Nov 2013 10:45:55 PST Received: by mail-ie0-f177.google.com with SMTP id e14so13071971iej.36 for ; Mon, 04 Nov 2013 10:45:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=nr/g71PQ0F5dj9t2KkvIMuZD6Na4TlHZYyEpjM730AQ=; b=IRfheEjiFyi2BXnfPbeNv1xGlokFPGSNqX73+eDpoKrMzAu18A+DsUruz5qd6/+0yM ZjcjypwbHsY3uFmQ+6lnMoY2JUPjBnhSGLAfjvZMm4bZ9UqN7Ycj3pIOsPwbC6Y2AbgW 3rEPml1osogl/tw2urWWfdWt/Awo5D+I2x+6kvC8TLfEEepEP2psw3JP3Qax7toguBll bTC2cMSkbhaX6p9kK29Jj2PklFLufQ+icXYmjPYZvwxBd7K9mVQ+wJ785wH8cHGUmm7C 2QSniJbwXNBAPdy6s3FczZ5KjF3rTTkBu5LfSVkUw8GANFvuyA4L7/AoNIsqOq8du9CS T9NQ== X-Gm-Message-State: ALoCoQnwKJbRFKUcdgfyHFtEhLcJ2pw0jL/r5yj7t2lc6xvrBqd/9C2GZqU/aqVjhS1G9buTBV131N6MEf6bSvI4jE66/5+52iSslVSZRveK1dOn+983Hx9q7/PBFgDW+GhgvXJl/bgP8piR2MKnVcWMZ5qtDIJs4Q== X-Received: by 10.50.1.102 with SMTP id 6mr13270399igl.0.1383590753709; Mon, 04 Nov 2013 10:45:53 -0800 (PST) X-Received: by 10.50.1.102 with SMTP id 6mr13270391igl.0.1383590753642; Mon, 04 Nov 2013 10:45:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.245.233 with HTTP; Mon, 4 Nov 2013 10:45:23 -0800 (PST) From: Brian Campbell Date: Mon, 4 Nov 2013 10:45:23 -0800 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org WG" Subject: [OAUTH-WG] audience (was draft-ietf-oauth-jwt-bearer-06) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 18:46:11 -0000 On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig wrote: > You write: > > " > 3. The JWT MUST contain an "aud" (audience) claim containing a > value that identifies the authorization server as an intended > audience. The token endpoint URL of the authorization server > MAY be used as a value for an "aud" element to identify the > authorization server as an intended audience of the JWT. JWTs > that do not identify the authorization server as an intended > audience MUST be rejected.... > " > > If the endpoint URL of the AS is not used then what else? Wouldn't it be > useful to say "The token endpoint URL of the authorization server > MUST be used as a value for an "aud" element to identify the > authorization server as an intended audience of the JWT."? This and the other assertion documents offer the token endpoint URL as one way to identify the AS for deployments which lack some other means of doing so. However, these assertion profiles are little slices of functionality that augment existing deployments of OAuth, often in conjunction with other 'federated' technologies for which there will be an existing and agreed upon identifier that the issuer is known by. This is not just academic - it's how these systems and deployment already work. It's inappropriate and unrealistic for this document (or the other assertion docs) to preclude common and useful deployment practices. > Then, I have a suggestion for re-phrasing this sentence from : > " > Audience values SHOULD be compared > using the Simple String Comparison method defined in Section > 6.2.1 of RFC 3986 [RFC3986], unless otherwise specified by the > application. > " > to: > > " > In the absence of an application profile standard specifying > otherwise, a compliant JWT Bearer application MUST compare the audience > values using the Simple String Comparison method defined in Section > 6.2.1 of RFC 3986 [RFC3986]. > " I think I'm okay with that re-phrasing. Do others (my co-authors especially) agree? Or object? > > The same can actually be applied to the issuer claim as well. As I said in the previous mail about issuer, I'd like to get rid of the comparison text. However, if such text stays, I'll work to make it consistent throughout. > Given that the JWT had been updated to align it with the JOSE work I suspect > that this document also requires an update. You may well be correct. But despite following the JOSE and JWT work, I'm not sure I know what update(s) would be required. Can you elaborate? From bcampbell@pingidentity.com Mon Nov 4 11:52:51 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4A721E80C9 for ; Mon, 4 Nov 2013 11:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.917 X-Spam-Level: X-Spam-Status: No, score=-5.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ud3sGGCC24AB for ; Mon, 4 Nov 2013 11:52:46 -0800 (PST) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with ESMTP id 5831721E821C for ; Mon, 4 Nov 2013 11:52:44 -0800 (PST) Received: from mail-ie0-f179.google.com ([209.85.223.179]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKUnf7DB5ShXTTP5qqWVu3SvtHxynGalpV@postini.com; Mon, 04 Nov 2013 11:52:44 PST Received: by mail-ie0-f179.google.com with SMTP id aq17so12790255iec.24 for ; Mon, 04 Nov 2013 11:52:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=mKgNVhKhACxFGaT9gEIyEGDciB8zPav8UzmF9jBwcuw=; b=gH6pclE+XWOiQn94BggKwGAAx4JEZT4insF5QHvllMwfTD3mcF4wl457j43OCm+dRW aOo7R5CkT5CGYZPEOtu3bng/5rQUI9jp60lnBtLgrkr1mu8IRPIFVv0W56BpRQDofjju 3j1YmowcBX8xcKHfZ4HaL1CLDZNmUFnwtigRgh8N2n4UT1Bm2mQ7DO5malhcBuULXSXz oFyq6wmWHW7JD9FobCFNujaKciW9uBymiGj+h1dL0Eolb2V9wHFuGIKw8GE0VN/tOvfs WqqKg0tnKu5VwmLhPtvciRaY9SM2JCc3vnrwuHBEZ3mcFM/B2hZr6aj6vXjDoCOL3z4w gfFw== X-Gm-Message-State: ALoCoQnjO6EMgVICWZOtD4bYnzqTMchJpO3NFEOaY5AqkXZ4FFsRMWe22wV6/0LZXmapjAIjXWZ3ijufQoVTG7nFbvgl88In4vCBu22mOot7+or6l6PRJA2tOowL1dfROgJeBBZXAfixd9AdlYeEAV8rW87RInMRmw== X-Received: by 10.42.142.129 with SMTP id s1mr11070976icu.30.1383594763928; Mon, 04 Nov 2013 11:52:43 -0800 (PST) X-Received: by 10.42.142.129 with SMTP id s1mr11070972icu.30.1383594763839; Mon, 04 Nov 2013 11:52:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.245.233 with HTTP; Mon, 4 Nov 2013 11:52:13 -0800 (PST) From: Brian Campbell Date: Mon, 4 Nov 2013 11:52:13 -0800 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org WG" Subject: [OAUTH-WG] Interoperability Considerations (was draft-ietf-oauth-jwt-bearer-06) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 19:52:51 -0000 On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig wrote: > > Section 5 about "Interoperability Considerations" says: > > " > Specific items that require agreement are as > follows: values for the issuer and audience identifiers, the location > of the token endpoint, and the key used to apply and verify the > digital signature or keyed message digest over the JWT. > " > > I believe that this list is not correct. The list could probably be expanded to include a mention of how subject is to be identified (related to discussion about subject [1]) as well as requirements the AS may place on upper limits of token expiration and/or de-duping. > What is needed is: > > * At the authorization server there needs to be a whitelist of trusted > issuers. For a succesful protocol run the JWT needs to be created by an > issuer who is in the whitelist. > > * Along with the entry in the whitelist of trusted issuers needs to be a > key. That's one implementation approach. But not the only one. The intent of this section is to note the information which needs to be exchanged/agreed upon in order for the wire protocol to work. That's all. Implementation particulars shouldn't be here. > There is no new endpoint URL defined by this document. As such, I wouldn't > mention those. No but there's been a request, which makes sense, to explicitly state the items which need to be known, typically via service documentation, in order to achieve interoperability. The token endpoint is one of those items and OAuth provides no means of discovering it or publishing it. So I feel it's very appropriate to mention it here. And, by way of example, if you look at service documentation for existing deployments, you'll see that it is included. > I also do not think that the audience identifier needs to be agreed if you > define it as the token endpoint URL of the authorization server (as I > suggested above). As I said in the previous mail on audience [2] and have been arguing/explaining for a long time now, that suggestion is not viable or realistic. And (as I mention above) the token endpoint URL *still* needs to be communicated somehow. Documenting the expected value for audience is just one more piece of information in a set of info that has to be exchanged anyway. [1] sub http://www.ietf.org/mail-archive/web/oauth/current/msg12250.html [2] aud http://www.ietf.org/mail-archive/web/oauth/current/msg12251.html From bcampbell@pingidentity.com Mon Nov 4 11:58:42 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400C721E8220 for ; Mon, 4 Nov 2013 11:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.921 X-Spam-Level: X-Spam-Status: No, score=-5.921 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFppq4z1gAdn for ; Mon, 4 Nov 2013 11:58:37 -0800 (PST) Received: from na3sys009aog134.obsmtp.com (na3sys009aog134.obsmtp.com [74.125.149.83]) by ietfa.amsl.com (Postfix) with ESMTP id E2F3811E8224 for ; Mon, 4 Nov 2013 11:58:36 -0800 (PST) Received: from mail-ie0-f173.google.com ([209.85.223.173]) (using TLSv1) by na3sys009aob134.postini.com ([74.125.148.12]) with SMTP ID DSNKUnf8bBmBqQ9rTuj+oQUfz6G8jHAXLAfq@postini.com; Mon, 04 Nov 2013 11:58:37 PST Received: by mail-ie0-f173.google.com with SMTP id u16so12969330iet.4 for ; Mon, 04 Nov 2013 11:58:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=AzgDWptuPn4QOIg0KVGPa34fDTqJLoICa+6lq1cBVhk=; b=RIJz+AK9bLtRpRXZT4gnwr3jONEUJnRYMEpP7ViYLi2Ht34NbP94psRQDUU3d8ikUc nPupSaiwj4+F6+e4m752kpCjm1zbHK1SPt7I7eE01iQLHIDGq5lVCIIQ20ccGwVq3Aod XVdZ7LPux+nMfwyVKd6BDbvMLtsYazql04UWjvCytLX4eFwl0rzQ519ZeO1tf6j4f6w1 kz6cuOw/Mzfv2qcG6Kh/mqK8MRro3NE45k7BNWBqD/gkhzyDVLDON+VslC0aw11gKwqv GFaehDf5IQcrzARLmc6bKlYHhrP6ZJOEl2ooRocOx4y69SO6cVCK/25aKI8UXFxGeiII 5olg== X-Gm-Message-State: ALoCoQmYUO/kNZpxhXRPa15mjITbR9FVBkrxei0ehBYYDxKacdxXUsOYhJrWhlUqW5wREuHs3SDHJWPQw9TxFS7oSc3EP5hrqgQ8g4UBM+Ur0g+4QLcjk/F8HxG1dkYoaCjAwdc8s/PCLPKvYJT403WahX28aqvw7Q== X-Received: by 10.43.138.8 with SMTP id iq8mr4678011icc.37.1383595112518; Mon, 04 Nov 2013 11:58:32 -0800 (PST) X-Received: by 10.43.138.8 with SMTP id iq8mr4678000icc.37.1383595112351; Mon, 04 Nov 2013 11:58:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.245.233 with HTTP; Mon, 4 Nov 2013 11:58:02 -0800 (PST) From: Brian Campbell Date: Mon, 4 Nov 2013 11:58:02 -0800 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org WG" Subject: [OAUTH-WG] audience (was draft-ietf-oauth-saml2-bearer-17) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 19:58:42 -0000 On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig wrote > Item #2: You wrote: > > " > Section 2.5.1.4 of Assertions and Protocols for the OASIS > Security Assertion Markup Language [OASIS.saml-core-2.0-os] > defines the and elements and, > in addition to the URI references discussed there, the token > endpoint URL of the authorization server MAY be used as a URI > that identifies the authorization server as an intended > audience. Assertions that do not identify the Authorization > Server as an intended audience MUST be rejected. > " > > The 'MAY' is extremely weak here. If you make it a MUST that there has to be > the endpoint URL of the authorization server in there then that would > provide so much more interoperability. As a reader I wouldn't know what > other options I have and systems that provision necessary databases / tables > to ensure that the comparison takes place will also struggle. The "MAY" is intended to be weak and is only a suggestion for deployments which don't already have a suitable identifier (like a SAML 2 entity ID) for an audience value. I understand that you'd like this to be tighter but the suggestion is not viable and it wouldn't provide the perceived interoperability panacea anyway. Some information needs to be agreed upon for this to work. How is out of scope here. The audience is one such value. Even if mandating one specific thing for audience was feasible, it wouldn't add to interoperability because there is other information that has to be agreed on anyway. > Then, there is again this SHOULD regarding the comparison operation, see > " > Audience > values SHOULD be compared using the Simple String Comparison > method defined in Section 6.2.1 of RFC 3986 [RFC3986], unless > otherwise specified by the application. > " > > I would replace it with a MUST, as I argued in > draft-ietf-oauth-jwt-bearer-06. As I said there [1], I think I'm okay with that but would like to hear from others in the WG. [1] http://www.ietf.org/mail-archive/web/oauth/current/msg12251.html From bcampbell@pingidentity.com Mon Nov 4 12:00:03 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A0721E8237 for ; Mon, 4 Nov 2013 12:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.925 X-Spam-Level: X-Spam-Status: No, score=-5.925 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83QiERlaB5b3 for ; Mon, 4 Nov 2013 11:59:58 -0800 (PST) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with ESMTP id 68A1D21E809A for ; Mon, 4 Nov 2013 11:59:29 -0800 (PST) Received: from mail-ie0-f178.google.com ([209.85.223.178]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKUnf8oXjkMfCWOtSCinhOVBPjWyySyZef@postini.com; Mon, 04 Nov 2013 11:59:29 PST Received: by mail-ie0-f178.google.com with SMTP id x13so13070288ief.23 for ; Mon, 04 Nov 2013 11:59:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=1csySJf+6ouQpQdWdTwudBCuvCQUjKbbim9Twfm1VNI=; b=nB3oY12R2FaAyPpfY+eDEW+c4QhcNupD16n3CAHposCrGh3YsJXcpHQQM5XtL/BxDv I7iHI1j8fsG3dLjmUg2tQuFtnDK6THqiJl28vaiR5TcGZSKm0S0+vqsHi8gJ16DuUlvn vOD6o9t9W1e0zoJKpT220AHRP2AURp9M6PoezQ6SHyCo2MMpx55sWqqNOESwbYQlqr2+ zVtExZoH+dGLqEv5eeNT6YY93GhSEluZDHkZvFvHl6e48p3ifN1RzHnVwmV7LgBCepf9 9fwy9anaXBeuD14/NkME2x/vFEs3B+bzVxe469lbJuS6d5Ha4enCbACBCZfhNNutg+gb vKqg== X-Gm-Message-State: ALoCoQlThcoVhQNfxozsQhB+oR8fJwJiNK8xzYmFEC72Yx8luZvB6OZeVNhFtuIFiEFY8cMZH1ihgTtK6uujrVj0ZQyuNgkaC8IoK61YIC0Ddu0uz/mKQAj+Q0SLtrUgfRiN3Anow8oAatBrpdsxTnLR0hYRnXIMlg== X-Received: by 10.50.126.74 with SMTP id mw10mr13478927igb.24.1383595166935; Mon, 04 Nov 2013 11:59:26 -0800 (PST) X-Received: by 10.50.126.74 with SMTP id mw10mr13478923igb.24.1383595166856; Mon, 04 Nov 2013 11:59:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.245.233 with HTTP; Mon, 4 Nov 2013 11:58:56 -0800 (PST) From: Brian Campbell Date: Mon, 4 Nov 2013 11:58:56 -0800 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org WG" Subject: [OAUTH-WG] Subject (was draft-ietf-oauth-saml2-bearer-17) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 20:00:04 -0000 On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig wrote: > > Item #3: As in the draft-ietf-oauth-jwt-bearer-06 this part is extremely > fluffy, except for the case where it talks about the client-id. What exactly > do I put into the field in the case of an authorization grant? Similar to sub in the JWT draft [1], the fluff is intended to allow for cases where the subject alone can't or shouldn't directly identify someone. I'm open to changes that would help clarify usage (and I think that warrants a mention in Interoperability Considerations) but any such text needs to be reflective of reality too. [1] http://www.ietf.org/mail-archive/web/oauth/current/msg12250.html From bcampbell@pingidentity.com Mon Nov 4 12:00:25 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBB621E8269 for ; Mon, 4 Nov 2013 12:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.928 X-Spam-Level: X-Spam-Status: No, score=-5.928 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LveuNdkKz-m1 for ; Mon, 4 Nov 2013 12:00:19 -0800 (PST) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with ESMTP id 059B121E80DE for ; Mon, 4 Nov 2013 11:59:58 -0800 (PST) Received: from mail-ie0-f172.google.com ([209.85.223.172]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKUnf8u+RJnbwHtmiwbzmRgT+JB56gPY7b@postini.com; Mon, 04 Nov 2013 11:59:59 PST Received: by mail-ie0-f172.google.com with SMTP id tp5so13508850ieb.17 for ; Mon, 04 Nov 2013 11:59:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=32u5OR4lboce9ITUGmxGeWT6oTOfp6d/nw9qTXhvXfQ=; b=MkCDr4lEAQM+2PD7Xz5of5CGwAzOFyvWTzJS/KBzsU0F/Mub5SBaKbYeJlgl5v7Qhc ghngz2/g+1YKjJG7ffVOdjmX9tuROMZjHd3MK1L3aCilZ3qHVtNFWvtnD+W29ED/P1/O BMkrs3kjwBYRjGRUJji03GOHI+sb3sDsdW8fT9KRmS1UHKdsyj8HT5sbtrtYyGfyKcEq DkO/UJeiUbF9087YZAMb5McICAWQPVbqJIbw2+Z6g1M61yK6WUpCkw40VupKRdzEuB2e XGhFnKElRaWLurhTl07KigZldOtuRcG+wNHapA4ukQdijceD06hGNEm2JIqvfGlWxvym 577w== X-Gm-Message-State: ALoCoQmkbCnIGt8E3mHWcBPO4/4bguhJIAokOQsYpKshsySHdl6NevuzRUWE5NBNLf2ypoktgGOfFQfxf9VQ0WU5XNQHj3ty4stlvMCb90lWSv0miat3w4ZzbsZi9dlpjlyU7FNcl5fKUcmusmwUYMoJQcESuad8qA== X-Received: by 10.50.56.44 with SMTP id x12mr13267218igp.41.1383595187911; Mon, 04 Nov 2013 11:59:47 -0800 (PST) X-Received: by 10.50.56.44 with SMTP id x12mr13267213igp.41.1383595187845; Mon, 04 Nov 2013 11:59:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.245.233 with HTTP; Mon, 4 Nov 2013 11:59:17 -0800 (PST) From: Brian Campbell Date: Mon, 4 Nov 2013 11:59:17 -0800 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org WG" Subject: [OAUTH-WG] Confirmation (was draft-ietf-oauth-saml2-bearer-17) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 20:00:25 -0000 On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig wrote: > Item #5: You write: > > " > The element MUST contain at least one > element that allows the authorization > server to confirm it as a Bearer Assertion. > " > > What do you mean that the AS confirms that it is a bearer assertion? Confirmation is a term from SAML which is honestly not well understood by many people (myself included) but I'm trying to be consistent with that in how I use it here. But it's not necessary and #5 is just stating how the element needs to look. Perhaps rewording it to just not use the confirm language would be better? > I think > what you rather want to say is that the AS indicates that it is a bearer > assertion. No, it's just language around what needs to be validated in the element of the assertion because it is a bearer assertion. From bcampbell@pingidentity.com Mon Nov 4 12:04:43 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA5811E8175 for ; Mon, 4 Nov 2013 12:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.931 X-Spam-Level: X-Spam-Status: No, score=-5.931 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6phuufh8geA for ; Mon, 4 Nov 2013 12:04:38 -0800 (PST) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by ietfa.amsl.com (Postfix) with ESMTP id DBBB021F9EED for ; Mon, 4 Nov 2013 12:04:34 -0800 (PST) Received: from mail-ie0-f175.google.com ([209.85.223.175]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKUnf90uTTdXhGq2peG3a4LL5xAxhUlzvl@postini.com; Mon, 04 Nov 2013 12:04:35 PST Received: by mail-ie0-f175.google.com with SMTP id aq17so12886543iec.6 for ; Mon, 04 Nov 2013 12:04:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=Bf6mO0ekPRkwcnV4nRWG6nZ2aeEDcniAIzw+V7iAICg=; b=TSlBMgYqxriTRawUBP6ZmhNtf4uB8nG9vbmLHBCvJGgqaguo3jbgWRLwzn0wYKh5pn /IZQmIENd4VJyITHZMiEgYEehdAfDBE5Uyx8zeUh5cNXh2ry0VPoYZrVQ+uie1DRsNS5 bB4CcUQHshkvvUBq+ChjxR1qyQ6FD+fCu7Hcups9oYVSztI4HEyUoARDIdpoZWQ6fU4q q7eXOewW6KcxJu+IEv6KZPbD4BuRdqMVdypVZMg6gg2I09JkjXe/FjnauCrT9MUfTL/H Wk6xQv1IZ5j7uzr+xXno4jHMGrSRBSLH2FdeQTqPIPPQfuC4XWXvTiDL1fXUPQDu5bow Ldlw== X-Received: by 10.42.142.129 with SMTP id s1mr11083983icu.30.1383595081579; Mon, 04 Nov 2013 11:58:01 -0800 (PST) X-Gm-Message-State: ALoCoQltw3wNnNV/C2ah/M1WgyUecU0gKGRnYaOoIfpKYafvfJGL8q6UV4d3CoN88mMu6en28jcBQil8mkA2H6s/+uo0+lqfOTCoqUDyM8SWmA5+PautuAQfoF79kMcena/ZKhT9fPRiuc/JBba/2uVofxsRnRbQ8g== X-Received: by 10.42.142.129 with SMTP id s1mr11083977icu.30.1383595081498; Mon, 04 Nov 2013 11:58:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.245.233 with HTTP; Mon, 4 Nov 2013 11:57:31 -0800 (PST) From: Brian Campbell Date: Mon, 4 Nov 2013 11:57:31 -0800 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org WG" Subject: [OAUTH-WG] issuer (was draft-ietf-oauth-saml2-bearer-17) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 20:04:43 -0000 On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig wrote: > Section 3: > > Item #1: You wrote: "Issuer > values SHOULD be compared using the Simple String Comparison > method defined in Section 6.2.1 of RFC 3986 [RFC3986], unless > otherwise specified by the application." > > I would put a MUST here. You can also use the text I proposed for > draft-ietf-oauth-jwt-bearer-06, which is text I copied from the TLS > specification. > > Also the comment regarding the comparison operation I made in > draft-ietf-oauth-jwt-bearer-06 is applicable here. Likewise my comments and response to your comments on draft-ietf-oauth-jwt-bearer-06 are applicable here [1]. But I'm not sure which text you are referring to from the TLS specification? Maybe I overlooked something. [1] http://www.ietf.org/mail-archive/web/oauth/current/msg12249.html From bcampbell@pingidentity.com Mon Nov 4 12:48:55 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F5F11E822F for ; Mon, 4 Nov 2013 12:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.934 X-Spam-Level: X-Spam-Status: No, score=-5.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPcFNtqAJr8E for ; Mon, 4 Nov 2013 12:48:49 -0800 (PST) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9A711E812A for ; Mon, 4 Nov 2013 12:48:49 -0800 (PST) Received: from mail-ie0-f169.google.com ([209.85.223.169]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKUngIMRZJtGDMacYsDJNp0mvZH2l9BihV@postini.com; Mon, 04 Nov 2013 12:48:49 PST Received: by mail-ie0-f169.google.com with SMTP id ar20so13770473iec.28 for ; Mon, 04 Nov 2013 12:48:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=LP12Cl0/cc6hVeTFDbW7slkEyhfqTliHGLROR57+Rkg=; b=bHKrdi4hL5KUUSVHRmV9njeHuI8uLV8vMK8nn6PTZ2RJ9bvzS/fCcjX07pkmFl7WRY WmMolhH+pUdJtfAS0p7DspfAP9FHgAk5FYxUpq+2RGAtxwaQUpKWhl1Qx2dmc73JRsyx 04OlFRkUs/DPyfuV8PYLZaiZ+VF2eaGY8P+0g4LnW1TfIU8OCB5iqP7RbP+JWy1BUjQK dELBn8BJN3C/iboOINLoF0RTquonf/XCkcyT3XD3srZXzzj7Rgn5PURDmPoD1NNDdAJ4 MFfug5++iQzmudmh8DG5CNFKFu1lGdav+54B/WORV0wQ4u2QDBdOIgX0w0d1FGK3vfJ9 adCA== X-Gm-Message-State: ALoCoQnr5FaL30iFNuoU4NPHmkT5Yxf9cHp2XgQrhEuaqCCr5ULlhXdYY2J8ZC67sMh+jZx8LW8Rru1RGyKCwGBHvXjqIGC3WTtjQ8s8KDnbo797I6HZtjGp7RZ07cH3kO+tDgCgPJGKCY+bPZmfRqOz+ig1QSDlZw== X-Received: by 10.50.126.74 with SMTP id mw10mr13647413igb.24.1383598128941; Mon, 04 Nov 2013 12:48:48 -0800 (PST) X-Received: by 10.50.126.74 with SMTP id mw10mr13647405igb.24.1383598128744; Mon, 04 Nov 2013 12:48:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.245.233 with HTTP; Mon, 4 Nov 2013 12:48:18 -0800 (PST) From: Brian Campbell Date: Mon, 4 Nov 2013 12:48:18 -0800 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org WG" Subject: [OAUTH-WG] AuthnStatement (was draft-ietf-oauth-saml2-bearer-17) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 20:48:55 -0000 On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig wrote: > Item #7+8: T I think you should combine the two items since they relate to > the same issue, namely when to include the element. Okay, #7&8 can be rolled up into one item. > There > are two questions: > > Q1: Has the subject been authenticated? > > If 'no', then the cannot be populated. > > If 'yes', then > Q2: Has the subject requested to be anonymous? > > If 'no', then the element is populated > with the subject's identity. > > If 'yes', then the MUST NOT be populated. > (or populated with a field that indicates that the subject > is anonymous; I don't know SAML enough to tell what the > right approach here is). #8 is about the client acting *autonomously* on behalf of the subject. Not *anonymously*. Autonomous was a term used in earlier drafts of RFC 6749 (maybe circa -10 of draft-ietf-oauth-v2) when talking about a client who was acting on its own without the user being present. > Then you write: > " > The presenter SHOULD > be identified in the or similar element in the > element, or by other available means like > SAML V2.0 Condition for Delegation Restriction > [OASIS.saml-deleg-cs]. > " > > Who is the presenter? Is the presenter the subject? The presenter is the thing that shows up with and presents the assertion to the AS. It's a term used in the SAML specs. In this case the presenter is the client. Maybe it's better to just say client here and not use the term presenter? From bcampbell@pingidentity.com Mon Nov 4 12:58:04 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F6E21E80A5 for ; Mon, 4 Nov 2013 12:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.936 X-Spam-Level: X-Spam-Status: No, score=-5.936 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuxXcdNR6zsp for ; Mon, 4 Nov 2013 12:57:58 -0800 (PST) Received: from na3sys009aog106.obsmtp.com (na3sys009aog106.obsmtp.com [74.125.149.77]) by ietfa.amsl.com (Postfix) with ESMTP id A4D4321E80D1 for ; Mon, 4 Nov 2013 12:57:58 -0800 (PST) Received: from mail-ie0-f180.google.com ([209.85.223.180]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKUngKVlPQD4XNGMOLeh/ErLJyby7Dn6ib@postini.com; Mon, 04 Nov 2013 12:57:58 PST Received: by mail-ie0-f180.google.com with SMTP id e14so12920038iej.25 for ; Mon, 04 Nov 2013 12:57:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=z1XjVXKIgldprbon8LQVzIgSCrpnU1SR+cQ0HVx/PVc=; b=BOvHag1BWqZQnywEoRzhsho1LTzMr90oWBMk//Gux8hAaRp+03b+I7Lsm3RmfocGst A7UNnmb3SDEE7Io8OMF2ze63VTOzh6G90IJumOJA5104p1ZadoQOAI8AP0cFJfIEAVAK Kl9rbD/icCaJNhQRhUe4yO47mrN8Sw+UiNiBupf9b/fYQP0Yk8vpyE8DlYAsI0u4EUvp Vpeu3LZvZjvuqoeBuY9wf2MHycxp5qcknz4a9vzIHj24k3vdT9cplI0lkC/S8490xgU+ eRmQAEHXc9AQAH0ktpTek7wq0Qo7Z09+Hliq+5PvgFMXKJGTaKNdJ2jbiSpZjm9mcvEs 50Tw== X-Gm-Message-State: ALoCoQkNSlww0yUC+QVabeBqhbdxgl7cnvU1dipiebC2nJ6CcSULHXq7JYDbED9WDhmx3gQw+fgBiyrIbj/JIOWgTnuOrAr8GYxVIDs6Flwj6icZT39pME/AtDjYyhCVf5NXAySLQJqNb/HI0NYPDl3AxWscLgJOPQ== X-Received: by 10.50.56.44 with SMTP id x12mr13460106igp.41.1383598678238; Mon, 04 Nov 2013 12:57:58 -0800 (PST) X-Received: by 10.50.56.44 with SMTP id x12mr13460098igp.41.1383598678132; Mon, 04 Nov 2013 12:57:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.245.233 with HTTP; Mon, 4 Nov 2013 12:57:28 -0800 (PST) From: Brian Campbell Date: Mon, 4 Nov 2013 12:57:28 -0800 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org WG" Subject: [OAUTH-WG] message digest and signature (was draft-ietf-oauth-saml2-bearer-17) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 20:58:04 -0000 On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig wrote: > Item #10: You write: > > " > 10. The Assertion MUST be digitally signed or have a keyed message > digest applied by the issuer. The authorization server MUST > reject assertions with an invalid signature or keyed message > digest. > " > > To my knowledge SAML assertions only support digitial signatures and no > keyed message digests. It's built on XML Dsig which does allow for MAC. AFAIK, there's nothing in SAML prohibiting it. But, to your point, in practice it's always an asymmetric digital signature. I don't think that this is not the first time we've discussed this point. Maybe omitting the mention of keyed message digests would avoid confusion? In practice I don't think anything would be lost for doing so. From bcampbell@pingidentity.com Mon Nov 4 13:20:34 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A58311E822B for ; Mon, 4 Nov 2013 13:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.938 X-Spam-Level: X-Spam-Status: No, score=-5.938 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CX36FPYWIYMM for ; Mon, 4 Nov 2013 13:20:23 -0800 (PST) Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with ESMTP id B50F411E8163 for ; Mon, 4 Nov 2013 13:19:54 -0800 (PST) Received: from mail-ie0-f172.google.com ([209.85.223.172]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKUngPetMWbRtSt/uS0TqVPXscuaQk8Jq/@postini.com; Mon, 04 Nov 2013 13:19:54 PST Received: by mail-ie0-f172.google.com with SMTP id tp5so13705696ieb.17 for ; Mon, 04 Nov 2013 13:19:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=V1uC18y/HHzrWFDECYdkRqNsR15GS2jc7AtmGyZsuZo=; b=AEIKRJvlEjoxagOlwLvGe8CmVwigjhIkP6S8yWy6YS0j9MD92sDy9gP9tcfRTZ7bU4 UnHnvN9afZ79vbNLMJp5zdy75UKvtUdmlHm9Cz+R0+woQEivMYFQ/ThVuC/y48d09F7C tjM7AkPXmgV5iTGKIQxklHypcOlf3Syha6b4QXwWucJCIM1O+3knterNG1yxMaOiktr9 wwu6qkYEXzmxt4m9hwVTW6AS9WCNGB4ILfDjk6P/GTzX6KeR+DkwsTi66kxj2yS/duaK 5JR2VYAMRlPDa8pv1uQcDLMRszIUNeex4WV/zT9QHo3myjrQ8YtZlicDMNqGfqqEdX7y FW8Q== X-Gm-Message-State: ALoCoQntYcPSQEP+jOYDPGbcMfImDPKalAOSbT/unKR7RyQ9XHUWzGlmNX8h4zonZsX3e3JdBuwfL0I1IrL0rZZ8HZKSQOlG3RlhGuV9mXc5AgeLAFW2M49wUtTad8NzXJuCJQCuA3kiiflYAQ3/xfG92J3nltymCQ== X-Received: by 10.50.126.74 with SMTP id mw10mr13741125igb.24.1383599994263; Mon, 04 Nov 2013 13:19:54 -0800 (PST) X-Received: by 10.50.126.74 with SMTP id mw10mr13741119igb.24.1383599994182; Mon, 04 Nov 2013 13:19:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.245.233 with HTTP; Mon, 4 Nov 2013 13:19:23 -0800 (PST) From: Brian Campbell Date: Mon, 4 Nov 2013 13:19:23 -0800 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org WG" Subject: [OAUTH-WG] Security Considerations (was draft-ietf-oauth-saml2-bearer-17) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 21:20:34 -0000 On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig wrote: > Security Consideration section: > > > I believe the section needs to say two things into addition to the reference > to the other specifications, which are already included in the security > consideration section: > > a) The specification does not mandate replay protection for the SAML > assertion usage for neither the authorization grant nor for the client > authentication. It is an optional feature. Okay, I'll add some text about that. I think a word or two about it should go into Interoperability Considerations as well. > b) There is actually no authentication happening when these SAML assertions > are used for client authentication and for the authorization grant (in the > classical definition of authentication). This may be surprising to some why > typically assume that the client would have to demonstrate proof of > possession of a secret, which isn't the case here. I'm not sure I fully understand what you mean. Maybe it's some semantics around "authentication." Can you explain more or propose some text? > It would have been possible to provide more enhanced funtionality (and SAML > supports this as well) but it is not provided in the specification. Maybe a > future specification will provide that functionalility. I think it is worth pointing out. Can you give some examples or propose some text? From sakimura@gmail.com Mon Nov 4 13:37:55 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A403F21E8168 for ; Mon, 4 Nov 2013 13:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.654 X-Spam-Level: X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YI0+DRvvnfiS for ; Mon, 4 Nov 2013 13:37:49 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C1E9821E8104 for ; Mon, 4 Nov 2013 13:37:48 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id hp15so5820890lab.19 for ; Mon, 04 Nov 2013 13:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oBKwPr9pn9wiW+6DrpmdmQPIZniMkhdevTYO3jjY2aE=; b=gMaEejmdHMyg1QrWrXrFu78JxoNn2gnCp/JJvT2t9udIeHn4EzJBeUbvlg7Pv7jv6w oRkDT09CeSZtSlsoBHvWrUU7D8GJzqb//R2xWw6GSq5MV4lAB0U3uIapsRPQIhkXLRVj nDlcHPNjpIrif+kw4yUnYLaATeirPADO/LYYX+oaptGsFcsaRNMT8iJkILp0tSwhS9/4 1cOVDHMXA3XbwWU6i7cnIIqt3h+UZagBi+zND7muxo03C/Nds1Z7hpXmr5xG0MvmAPrG A84QNWDkwVnnnxKHy2+M/WadGWfRMWQp6wLPLXuSk8qz5EkJXWLOPaWKHU2NuLKyWe1X 17jQ== MIME-Version: 1.0 X-Received: by 10.112.200.170 with SMTP id jt10mr3064461lbc.10.1383601067554; Mon, 04 Nov 2013 13:37:47 -0800 (PST) Received: by 10.112.134.38 with HTTP; Mon, 4 Nov 2013 13:37:47 -0800 (PST) In-Reply-To: <5273F7A2.70409@gmx.net> References: <5273E5AD.7010408@gmx.net> <3F75FA0B-CAC3-439A-866B-CFE116FADA4E@ve7jtb.com> <5273F7A2.70409@gmx.net> Date: Tue, 5 Nov 2013 06:37:47 +0900 Message-ID: From: Nat Sakimura To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11c265b8247f8c04ea60ba80 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 21:37:56 -0000 --001a11c265b8247f8c04ea60ba80 Content-Type: text/plain; charset=ISO-8859-1 Since the client_id is supposed to be opaque, it would probably be better to JWE encrypt (note: all JWE encryption are integrity protected as well) by the authorization server upon issuing it to the client. This way, we have exactly one way of doing the things, and it works for both symmetric and asymmetric case. I see this more useful in the case of symmetric client secret. If the client were just using public key crypto to authenticate itself to the server, using the URI of the location of the client metadata as the client_id would suffice. This has an advantage of smaller client_id. 2013/11/2 Hannes Tschofenig > Hi John, > > thanks for the super-quick response. > > > Am 01.11.13 19:18, schrieb John Bradley: > > The client_id would continue to be opaque to the client as it is now. >> The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and >> provide integrity if it is using a symmetric key (probably the >> simplest thing if we are talking about a single registration endpoint >> paired with a single AS) In more complicated scenarios where perhaps >> a group of AS share a single registration endpoint you probably want >> to use asymmetric signature then asymmetric encryption + integrity. >> Those are deployment decisions that need to be documented but can be >> transparent to teh client. >> > > Maybe it would be good to state that in the document that this is a > possible option without introducing further complications (other than the > verification procedure is different). If the AS signs the JWT then it just > needs to compare whether the issuer field matches what it had previously > put in there. If someone else signs the JWT then it needs to check with > some trust anchor store or something similar whether it trusts that > specific issuer. > > > > >> Sorry to my mind it is obvious that the JWT would be integrity >> protected/signed for all clients including clients using asymmetric >> authentication to the token endpoint, and and >> signed+encrypted+integrity for clients using symmetric >> authentication. That can be made clearer. >> > > It would be good to say that because the effort is rather low and there > are benefits in doing so. > > > >> It might make sense to assume the issuer is just the AS but the AS >> can do that without the benefit of a spec now, as there is no >> interoperability issue. >> >> The spec defining the JWT structure and signing and encryption >> methods has the most benefit when you don't have such a tight >> coupling between registration and AS. >> >> That is likely why Justin and I didn't think a spec was necessary for >> the simple case other than to show people this is possible with the >> existing registration spec. >> > > I think there is value in providing that information for implementers even > though it does not require new extensions or so. > > > >> I am OK with strengthening the wording on signing/integrity >> protecting and encryption. eg if a symmetric key is included the JWT >> MUST be encrypted. >> > > Cool. > > >> I don't necessarily want to make any algorithm a must as that limits >> algorithm agility in the future. >> > OK. > > > >> Thanks for giving it a read, see you Sunday I expect. >> > Unfortunately not since I am unable to attend the upcoming IETF meeting. > Derek will run the show. > > Ciao > Hannes > > > >> John B. >> >> >> On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig >> wrote: >> >> Hi John, Hi all, >>> >>> I read your document and here a few remarks. >>> >>> In the dynamic client registration conference calls the topic of >>> the stateless client was raised since there was the argument in the >>> air that the current OAuth 2.0 RFC requires clients to be stateless >>> due to the nature of the client identifier. >>> >>> It seems that you have found a way to make the client stateless >>> with regard to the client identifier (i.e., that the authorization >>> server does not need to store information about the client) by >>> dumping state information in the client identifier itself. In your >>> case you use a JWT, which is clever. >>> >>> Since RFC 6749 explicitly says that the client identifier string >>> size is left undefined and that the client should avoid making >>> assumptions about the identifier size I don't see a problem with >>> the proposed approach. >>> >>> Now, there is one issue that I am wondering about. The client >>> identifier itself is not sufficient for authorizing the client (for >>> confidential clients). Instead, there is typically the need to have >>> a secret. Now, the secret is not conveyed in the JWT, at least not >>> in the way you have define it. You could of course do that and >>> there is a document that provides prior art, see >>> http://www.ietf.org/rfc/rfc5077 The story essentially is that the >>> structure (JWT in your case) includes the key but of course then >>> you have to encrypt the entire blob. >>> >>> In the case of public clients wouldn't you want to mandate at least >>> a digital signature or a keyed message digest for the JWT since >>> otherwise there is the risk that the client changes some of the >>> parameters to impersonate someone? >>> >>> A few other questions: >>> >>> * You write: "The issuer SHOULD sign the JWT with JWS in such a way >>> that the signature can be verified by the authorization server. " >>> >>> I believe what you want to say is the following: The authorization >>> creates the client identifier (using the JWT) and the client does >>> not parse the received content since it treats it as opaque. >>> However, the authorization server MUST be able to process and >>> verify received client identifiers it previously created, which >>> requires to apply cryptographic processing when a JWT is signed >>> (using a JWS) and when a JWT is encrypted (using a JWE). >>> >>> (I ignore the issue that I believe the JWT needs to be signed [for >>> public clients] and encrypted [for confidential clients].) >>> >>> * You should submit the document as draft-bradley-oauth; this makes >>> it easier to find the document. >>> >>> * You write: " The issuer MAY encrypt the JWT with JWE. " >>> >>> I think you want to be stronger by saying that JWE MUST be used >>> when the authorization server wants to apply confidentiality >>> protection of the JWT. While the authorization server could use >>> other techniques as well the purpose of the document is to describe >>> one way to accomplish the goal and therefore it makes sense to be >>> specific. >>> >>> I would even go as far as suggesting specific algorithms to use, as >>> an example. >>> >>> * Although not stated directly I believe you allow the client >>> identifier to be created by a party other than the authorization >>> server. While this would theoretically make sense wouldn't it be >>> useful to just assume that the issuer is the authorization server? >>> >>> Ciao Hannes _______________________________________________ OAuth >>> mailing list OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c265b8247f8c04ea60ba80 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Since the client_id is supposed to be opaque, it would pro= bably be better to JWE encrypt (note: all JWE encryption are integrity prot= ected as well) by the authorization server upon issuing it to the client. T= his way, we have exactly one way of doing the things, and it works for both= symmetric and asymmetric case.=A0

I see this more useful in the case of symmetric client secre= t.=A0

If the client were just using public key cry= pto to authenticate itself to the server, using the URI of the location of = the client metadata as the client_id would suffice.=A0

This has an advantage of smaller client_id.=A0


2013/11/2 = Hannes Tschofenig <hannes.tschofenig@gmx.net>
Hi John,

thanks for the super-quick response.


Am 01.11.13 19:18, schrieb John Bradley:

The client_id would continue to be opaque to the client as it is now.
The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and
provide integrity if it is using a symmetric key (probably the
simplest thing if we are talking about a single registration endpoint
paired with a single AS) =A0In more complicated scenarios where perhaps
a group of AS share a single registration endpoint you probably want
to use asymmetric signature =A0then asymmetric encryption + integrity.
Those are deployment decisions that need to be documented but can be
transparent to teh client.

Maybe it would be good to state that in the document that this is a possibl= e option without introducing further complications (other than the verifica= tion procedure is different). If the AS signs the JWT then it just needs to= compare whether the issuer field matches what it had previously put in the= re. If someone else signs the JWT then it needs to check with some trust an= chor store or something similar whether it trusts that specific issuer.



Sorry to my mind it is obvious that the JWT would be integrity
protected/signed for all clients including clients using asymmetric
authentication to the token endpoint, and and
signed+encrypted+integrity for clients using symmetric
authentication. =A0 That can be made clearer.

It would be good to say that because the effort is rather low and there are= benefits in doing so.



It might make sense to assume the issuer is just the AS but the AS
can do that without the benefit of a spec now, as there is no
interoperability issue.

The spec defining the JWT structure and signing and encryption
methods has the most benefit when you don't have such a tight
coupling between registration and AS.

That is likely why Justin and I didn't think a spec was necessary for the simple case other than to show people this is possible with the
existing registration spec.

I think there is value in providing that information for implementers even = though it does not require new extensions or so.



I am OK with strengthening the wording on signing/integrity
protecting and encryption. =A0eg if a symmetric key is included the JWT
MUST be encrypted.

Cool.


I don't necessarily want to make any algorithm a must as that limits algorithm agility in the future.
OK.



Thanks for giving it a read, see you Sunday I expect.
Unfortunately not since I am unable to attend the upcoming IETF meeting. De= rek will run the show.

Ciao
Hannes



John B.


On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig
<hannes.t= schofenig@gmx.net> wrote:

Hi John, Hi all,

I read your document and here a few remarks.

In the dynamic client registration conference calls the topic of
the stateless client was raised since there was the argument in the
air that the current OAuth 2.0 RFC requires clients to be stateless
due to the nature of the client identifier.

It seems that you have found a way to make the client stateless
with regard to the client identifier (i.e., that the authorization
server does not need to store information about the client) by
dumping state information in the client identifier itself. In your
case you use a JWT, which is clever.

Since RFC 6749 explicitly says that the client identifier string
size is left undefined =A0and that the client should avoid making
assumptions about the identifier size I don't see a problem with
the proposed approach.

Now, there is one issue that I am wondering about. The client
identifier itself is not sufficient for authorizing the client (for
confidential clients). Instead, there is typically the need to have
a secret. Now, the secret is not conveyed in the JWT, at least not
in the way you have define it. You could of course do that and
there is a document that provides prior art, see
http://www.ie= tf.org/rfc/rfc5077 The story essentially is that the
structure (JWT in your case) includes the key but of course then
you have to encrypt the entire blob.

In the case of public clients wouldn't you want to mandate at least
a digital signature or a keyed message digest for the JWT since
otherwise there is the risk that the client changes some of the
parameters to impersonate someone?

A few other questions:

* You write: "The issuer SHOULD sign the JWT with JWS in such a way that the signature can be verified by the authorization server. "

I believe what you want to say is the following: The authorization
creates the client identifier (using the JWT) and the client does
not parse the received content since it treats it as opaque.
However, the authorization server MUST be able to process and
verify received client identifiers it previously created, which
requires to apply cryptographic processing when a JWT is signed
(using a JWS) and when a JWT is encrypted (using a JWE).

(I ignore the issue that I believe the JWT needs to be signed [for
public clients] and encrypted [for confidential clients].)

* You should submit the document as draft-bradley-oauth; this makes
it easier to find the document.

* You write: " The issuer MAY encrypt the JWT with JWE. "

I think you want to be stronger by saying that JWE MUST be used
when the authorization server wants to apply confidentiality
protection of the JWT. While the authorization server could use
other techniques as well the purpose of the document is to describe
one way to accomplish the goal and therefore it makes sense to be
specific.

I would even go as far as suggesting specific algorithms to use, as
an example.

* Although not stated directly I believe you allow the client
identifier to be created by a party other than the authorization
server. While this would theoretically make sense wouldn't it be
useful to just assume that the issuer is the authorization server?

Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf= .org
h= ttps://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en
--001a11c265b8247f8c04ea60ba80-- From phil.hunt@oracle.com Mon Nov 4 13:38:39 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A0B21E8189 for ; Mon, 4 Nov 2013 13:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.158 X-Spam-Level: X-Spam-Status: No, score=-5.158 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, TVD_SPACE_RATIO=2.219, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXhXXdQ6q-sK for ; Mon, 4 Nov 2013 13:38:31 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0D06321E8102 for ; Mon, 4 Nov 2013 13:38:31 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA4LcQIA001896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Nov 2013 21:38:27 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA4LcNAI007337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Nov 2013 21:38:24 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA4LcNtW029952; Mon, 4 Nov 2013 21:38:23 GMT Received: from dhcp-a540.meeting.ietf.org (/31.133.165.64) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Nov 2013 13:38:22 -0800 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_3F857C31-D11A-4409-83C7-381391E8C301" Date: Mon, 4 Nov 2013 13:38:20 -0800 Message-Id: <61F254BC-8043-447B-81E5-5286D69EE021@oracle.com> To: Derek Atkins , Hannes Tschofenig Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "oauth@ietf.org WG" Subject: [OAUTH-WG] Discussion slides for registration discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 21:38:39 -0000 --Apple-Mail=_3F857C31-D11A-4409-83C7-381391E8C301 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_3F857C31-D11A-4409-83C7-381391E8C301 Content-Type: multipart/mixed; boundary="Apple-Mail=_9B3DF8EC-07F0-4F7C-AE6D-8D989DAC852F" --Apple-Mail=_9B3DF8EC-07F0-4F7C-AE6D-8D989DAC852F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii = --Apple-Mail=_9B3DF8EC-07F0-4F7C-AE6D-8D989DAC852F Content-Disposition: inline; filename=OAuth-registration-IETF88.pdf Content-Type: application/pdf; name="OAuth-registration-IETF88.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAFtUstOwzAQvPsrhrfTUtfrR9zwFogLt0qWOFBOERWHFqnk /yXWbuIgqH3wZDO7s571DkvsoKGV5mWscX5BCNSohhe80/j+wCu+MH/qCG0HyrtrOcnbnrYtGaLE NiXWF7c6NHZhsSlyY+QT60lSMEmBu+HdtWLHUgkSalKUG7JOqxA82i0eI5zL//nwWvlQU8CMP+IW 8xg5hTPjGm+QR8eVmGllIU8q7MFpBh7yLAOCPL+ouFUHuZIJMHlVDaTJQJpeViKTZmoIzTNgus6A C5SSlCPmYCWTREhIO2QVjQJG/YMa74gveI48Qr69Dca7hnvr0RhjK3nGg5VEXhkYmy6xd5H94Nl7 xBbWZEP5oDooY9nMmTXiv6EuNcSe+XRVPuvQg0Vzdc1wbO2vMjVGObFX/iUXvNKWDMs1qg7p7f0X vclOsdptP6jeOiGnd4OJxfr7nvOQbc4zGZta/gCbQJHzCmVuZHN0cmVhbQplbmRvYmoKNSAwIG9i agozNTQKZW5kb2JqCjIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3Vy Y2VzIDYgMCBSIC9Db250ZW50cyA0IDAgUiAvTWVkaWFCb3ggWzAgMCA3MjAgNTQwXQo+PgplbmRv YmoKNiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3My IDggMCBSIC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwKL1RUMS4xIDEwIDAgUiA+PiA+PgplbmRvYmoK MTEgMCBvYmoKPDwgL0xlbmd0aCAxMiAwIFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnZZ3VFPZFofPvTe90BIiICX0GnoJINI7SBUE UYlJgFAChoQmdkQFRhQRKVZkVMABR4ciY0UUC4OCYtcJ8hBQxsFRREXl3YxrCe+tNfPemv3HWd/Z 57fX2Wfvfde6AFD8ggTCdFgBgDShWBTu68FcEhPLxPcCGBABDlgBwOFmZgRH+EQC1Py9PZmZqEjG s/buLoBku9ssv1Amc9b/f5EiN0MkBgAKRdU2PH4mF+UClFOzxRky/wTK9JUpMoYxMhahCaKsIuPE r2z2p+Yru8mYlybkoRpZzhm8NJ6Mu1DemiXho4wEoVyYJeBno3wHZb1USZoA5fco09P4nEwAMBSZ X8znJqFsiTJFFBnuifICAAiUxDm8cg6L+TlongB4pmfkigSJSWKmEdeYaeXoyGb68bNT+WIxK5TD TeGIeEzP9LQMjjAXgK9vlkUBJVltmWiR7a0c7e1Z1uZo+b/Z3x5+U/09yHr7VfEm7M+eQYyeWd9s 7KwvvRYA9iRamx2zvpVVALRtBkDl4axP7yAA8gUAtN6c8x6GbF6SxOIMJwuL7OxscwGfay4r6Df7 n4Jvyr+GOfeZy+77VjumFz+BI0kVM2VF5aanpktEzMwMDpfPZP33EP/jwDlpzcnDLJyfwBfxhehV UeiUCYSJaLuFPIFYkC5kCoR/1eF/GDYnBxl+nWsUaHVfAH2FOVC4SQfIbz0AQyMDJG4/egJ961sQ MQrIvrxorZGvc48yev7n+h8LXIpu4UxBIlPm9gyPZHIloiwZo9+EbMECEpAHdKAKNIEuMAIsYA0c gDNwA94gAISASBADlgMuSAJpQASyQT7YAApBMdgBdoNqcADUgXrQBE6CNnAGXARXwA1wCwyAR0AK hsFLMAHegWkIgvAQFaJBqpAWpA+ZQtYQG1oIeUNBUDgUA8VDiZAQkkD50CaoGCqDqqFDUD30I3Qa ughdg/qgB9AgNAb9AX2EEZgC02EN2AC2gNmwOxwIR8LL4ER4FZwHF8Db4Uq4Fj4Ot8IX4RvwACyF X8KTCEDICAPRRlgIG/FEQpBYJAERIWuRIqQCqUWakA6kG7mNSJFx5AMGh6FhmBgWxhnjh1mM4WJW YdZiSjDVmGOYVkwX5jZmEDOB+YKlYtWxplgnrD92CTYRm40txFZgj2BbsJexA9hh7DscDsfAGeIc cH64GFwybjWuBLcP14y7gOvDDeEm8Xi8Kt4U74IPwXPwYnwhvgp/HH8e348fxr8nkAlaBGuCDyGW ICRsJFQQGgjnCP2EEcI0UYGoT3QihhB5xFxiKbGO2EG8SRwmTpMUSYYkF1IkKZm0gVRJaiJdJj0m vSGTyTpkR3IYWUBeT64knyBfJQ+SP1CUKCYUT0ocRULZTjlKuUB5QHlDpVINqG7UWKqYup1aT71E fUp9L0eTM5fzl+PJrZOrkWuV65d7JU+U15d3l18unydfIX9K/qb8uAJRwUDBU4GjsFahRuG0wj2F SUWaopViiGKaYolig+I1xVElvJKBkrcST6lA6bDSJaUhGkLTpXnSuLRNtDraZdowHUc3pPvTk+nF 9B/ovfQJZSVlW+Uo5RzlGuWzylIGwjBg+DNSGaWMk4y7jI/zNOa5z+PP2zavaV7/vCmV+SpuKnyV IpVmlQGVj6pMVW/VFNWdqm2qT9QwaiZqYWrZavvVLquNz6fPd57PnV80/+T8h+qwuol6uPpq9cPq PeqTGpoavhoZGlUalzTGNRmabprJmuWa5zTHtGhaC7UEWuVa57VeMJWZ7sxUZiWzizmhra7tpy3R PqTdqz2tY6izWGejTrPOE12SLls3Qbdct1N3Qk9LL1gvX69R76E+UZ+tn6S/R79bf8rA0CDaYItB m8GooYqhv2GeYaPhYyOqkavRKqNaozvGOGO2cYrxPuNbJrCJnUmSSY3JTVPY1N5UYLrPtM8Ma+Zo JjSrNbvHorDcWVmsRtagOcM8yHyjeZv5Kws9i1iLnRbdFl8s7SxTLessH1kpWQVYbbTqsPrD2sSa a11jfceGauNjs86m3ea1rakt33a/7X07ml2w3Ra7TrvP9g72Ivsm+zEHPYd4h70O99h0dii7hH3V Eevo4bjO8YzjByd7J7HTSaffnVnOKc4NzqMLDBfwF9QtGHLRceG4HHKRLmQujF94cKHUVduV41rr +sxN143ndsRtxN3YPdn9uPsrD0sPkUeLx5Snk+cazwteiJevV5FXr7eS92Lvau+nPjo+iT6NPhO+ dr6rfS/4Yf0C/Xb63fPX8Of61/tPBDgErAnoCqQERgRWBz4LMgkSBXUEw8EBwbuCHy/SXyRc1BYC QvxDdoU8CTUMXRX6cxguLDSsJux5uFV4fnh3BC1iRURDxLtIj8jSyEeLjRZLFndGyUfFRdVHTUV7 RZdFS5dYLFmz5EaMWowgpj0WHxsVeyR2cqn30t1Lh+Ps4grj7i4zXJaz7NpyteWpy8+ukF/BWXEq HhsfHd8Q/4kTwqnlTK70X7l35QTXk7uH+5LnxivnjfFd+GX8kQSXhLKE0USXxF2JY0muSRVJ4wJP QbXgdbJf8oHkqZSQlKMpM6nRqc1phLT4tNNCJWGKsCtdMz0nvS/DNKMwQ7rKadXuVROiQNGRTChz WWa7mI7+TPVIjCSbJYNZC7Nqst5nR2WfylHMEeb05JrkbssdyfPJ+341ZjV3dWe+dv6G/ME17msO rYXWrlzbuU53XcG64fW+649tIG1I2fDLRsuNZRvfbore1FGgUbC+YGiz7+bGQrlCUeG9Lc5bDmzF bBVs7d1ms61q25ciXtH1YsviiuJPJdyS699ZfVf53cz2hO29pfal+3fgdgh33N3puvNYmWJZXtnQ ruBdreXM8qLyt7tX7L5WYVtxYA9pj2SPtDKosr1Kr2pH1afqpOqBGo+a5r3qe7ftndrH29e/321/ 0wGNA8UHPh4UHLx/yPdQa61BbcVh3OGsw8/rouq6v2d/X39E7Ujxkc9HhUelx8KPddU71Nc3qDeU NsKNksax43HHb/3g9UN7E6vpUDOjufgEOCE58eLH+B/vngw82XmKfarpJ/2f9rbQWopaodbc1om2 pDZpe0x73+mA050dzh0tP5v/fPSM9pmas8pnS8+RzhWcmzmfd37yQsaF8YuJF4c6V3Q+urTk0p2u sK7ey4GXr17xuXKp2737/FWXq2euOV07fZ19ve2G/Y3WHruell/sfmnpte9tvelws/2W462OvgV9 5/pd+y/e9rp95Y7/nRsDiwb67i6+e/9e3D3pfd790QepD14/zHo4/Wj9Y+zjoicKTyqeqj+t/dX4 12apvfTsoNdgz7OIZ4+GuEMv/5X5r0/DBc+pzytGtEbqR61Hz4z5jN16sfTF8MuMl9Pjhb8p/rb3 ldGrn353+71nYsnE8GvR65k/St6ovjn61vZt52To5NN3ae+mp4req74/9oH9oftj9MeR6exP+E+V n40/d3wJ/PJ4Jm1m5t/3hPP7CmVuZHN0cmVhbQplbmRvYmoKMTIgMCBvYmoKMjYxMgplbmRvYmoK OCAwIG9iagpbIC9JQ0NCYXNlZCAxMSAwIFIgXQplbmRvYmoKMTMgMCBvYmoKPDwgL0xlbmd0aCAx NCAwIFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4K c3RyZWFtCngBhVXfb9tUFD6Jb1KkFj8gWEeHisWvVVNbuRsarcYGSZOl7UoWpenYKiTkOjeJqRsH 2+m2qk97gTcG/AFA2QMPSDwhDQZie9n2wLRJU4cqqklIe+jEDyEm7QVV4bt2YidTxFz1+ss53znn O+de20Q9X2m1mhlViJarrp3PJJWTpxaUnk2K0rPUSwPUq+lOLZHLzRIuwRX3zuvhHYoIy+2R7v5O 9iO/eovc0YkiT8BuFR19GfgMUczUa7ZLFL8H+/hptwbc8xzw0zYEAqsCl32cEnjRxyc9TiE/CY7Q KusVrQi8Bjy82GYvt2FfAxjIk+FVbhu6ImaRs62SYXLP4S+Pcbcx/w8um3X07F2DWPucpbljuA+J 3iv2VL6JP9e19BzwS7Bfr7lJYX8F+I/60nwCeB9R9KmSfXTe50dfX60U3gbeBXvRcKcLTftqdTF7 HBix0fUl65jIIzjXdWcSs6QXgO9W+LTYY+iRqMhTaeBh4MFKfaqZX5pxVuaE3cuzWpnMAiOPZL+n zeSAB4A/tK28qAXN0jo3M6IW8ktXa26uqUHarppZUQv9Mpk7Xo/IKW27lcKUH8sOunahGcsWSsbR 6SZ/rWZ6ZxHa2AW7nhfakJ/d0ux0Bhh52D+8Oi/mBhzbXdRSYrajwEfoREQjThYtYtWpSjukUJ4y lMS9RjY8JTLIhIXDy2ExIk/SEmzdeTmP48eEjLIXvS2iUaU7x69wv8mxWD9T2QH8H2Kz7DAbZxOk sDfYm+wIS8E6wQ4FCnJtOhUq030o9fO8T3VUFjpOUPL8QH0oiFHO2e8a+s2P/oaasEsr9CNP0DE0 W+0TIAcTaHU30j6na2s/7A48yga7+M7tvmtrdPxx843di23HNrBuxrbC+NivsS38bVICO2B6ipah yvB2wgl4Ix09XAHTJQ3rb+BZ0NpS2rGjper5gdAjJsE/yD7M0rnh0Kr+ov6pbqhfqBfU3ztqhBk7 piR9Kn0r/Sh9J30v/UyKdFm6Iv0kXZW+kS4FObvvvZ8l2HuvX2ET3YpdaNVrnzUnU07Ke+QX5ZT8 vPyyPBuwFLlfHpOn5L3w7An2zQz9Hb0YdAqzak21ey3xBBg0DyUGnQbXxlTFhKt0Flnbn5OmUjbI xtj0I6d2XJzllop4Op6KJ0iJ74tPxMfiMwK3nrz4XvgmsKYD9f6TEzA6OuBtLEwlyDPinTpxVkX0 CnSb0M1dfgbfDqJJq3bWNsoVV9mvqq8pCXzKuDJd1UeHFc00Fc/lKDZ3uL3Ci6MkvoMijuhB3vu+ RXbdDG3uW0SH/8I761ZoW6gTfe0Q9b8a2obwTnzmM6KLB/W6veLno0jkBpFTOrDf+x3pS+LddLfR eID3Vc8nRDsfNxr/rjcaO18i/xbRZfM/WQBxeAplbmRzdHJlYW0KZW5kb2JqCjE0IDAgb2JqCjEw NDcKZW5kb2JqCjcgMCBvYmoKWyAvSUNDQmFzZWQgMTMgMCBSIF0KZW5kb2JqCjE2IDAgb2JqCjw8 IC9MZW5ndGggMTcgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ab1Y227cNhB9 51dMGrjhWpVWpKSV1EuAxLHTbNK0DgT0Ic7TokFRxAUcf1P+x5+UIcWZoZbai1O49sNqKYlnOOfM 4XBv4BJuoISyKPHPVrZuOgOt6Yse/6CpS/j8F/wJ/8Ly7NbA5haM/7/d4EtNFR675jcUj33isTB5 VbZ91VXwieFk5G/4eOoQrEPAaPD/dqNuEMpdGqirwviA6r4v2rbuYXMNzweoa/8AfpiqLTpbVpDj l+EalsNgChfr8BHeK/14AXlZVKCf+osa9A8LjAs/n2x9nvgHDOgf3Q0L+pkfwIvODyjNTzwPr9JU SwI5IxAeOaVZ8xf+qgF9ulAYEgLhfB9gWMP54MlI12xcoOOCqzE5/iO3tFJblMqvVH9ZwPDPOBMR RulEno+cGvGa0vaYS1urMZeY/zGX+tEEYULYAQQlwdt21JtDSNgCbXyOMOXnIcMlJTS/CCRcLSiP 1o2MaRzz+T1ReqXdLSRdHmYeMiItL4gHJovRmGnSwsqj76Ss7YNMq84WtRopsyuvUf+Ru4VXrrLG tCJxIa13k7T6ShPikNyxDqYAQRMCYOqibvp+hWmd4sT0qUggu+g7gGMtCgTtQnCCTKTkQL8kgrI8 I0Z+JWIrIhTLYU780wCSTJqyLjqzqiWAGRUxe6/46jvPNSqiCcqgwEgNJDh+g9TFZStaerJQ3kFY Lhm/JQ+x4Pheag6Ynq2ZCp8eFLXYBQeQhLimXBKq0q/9EJrM9vro+yTm/QQ05oGl7AD+DylHOH67 q2DYgBTPYVHrZXnydPlijVRSDc14aoWbJ61HHK+EvDKFDXUidf9F5jrGsKPJIzsVw3YYoRTimud4 t/fYOcv2GKHkZAFi2RFGXO+7TFvpYNqxD1NZcVW88YpFy2cXppIkyZ6QT0s574LEuhn3iR2QH9Se 7TZKMcjyK+wvVm3XjjSK24z77nvQv/FuQ9DZvLVxLzMPVBssh5XtJ3rhPLtmYY/2bFc9nPaiyR9M ex7j/tp7SX4X7TXBMBV7IFsxX7D6fvbvo9/+4vYF7Ap5f8q4YWT9sVTZksl4xW8P+iurwNYt+6vI LdhF0ibc0y7mJ/92u5hryT1G0p4etIs3vpyx4I/N4tjcEUHMYbhQYhzkLcIK9niu/Ud+2V2YINYA 2YqSzoWffhvahd9D/5en5hQApkoct3UyBHIyxpaGwYHPbsMYtT/4WGcLSWGgTGYbaA6cm43tDCjN UUiPcVQQgWrMp28Bh83EDNqiN81cVPriSl+gJabu1e5fo+kQydSuqZ07KzB/pAw6lT3Cgp1NKTXp xjXpSePhUjptnv1mrfAcqe8k/D2bNfeu8wBpk/6NZ6w5HLWvn5FdK5yLQe/2MvFNFkrGRcdJ502P CoKVxw565gs9OmmvfTHigMzChznG4ntUzWznOUfBF1RYPMBv/+Gx0GX4Fgf41jXdeBQ4XNP8brS7 TGs6qqbskiAxiP36ixpSoS3SX9Is3ld/AhDpItXf/RrG9DBqBGdvP53oT+mfgqEyYaQjopQFJm4u dNDDR53hs/Owt7MnEgZPGBhTW7/ESKFZ+SVmlrFkv75bxMftrWM9/x5zACBl7D87hiwkUkZ6AkoY mz/Wc20mGY1TO+7A76j6iQ6mfk136DjMvxbkbCbcLLitU6rr8ivVqQpsCmVuZHN0cmVhbQplbmRv YmoKMTcgMCBvYmoKMTI0OQplbmRvYmoKMTUgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAz IDAgUiAvUmVzb3VyY2VzIDE4IDAgUiAvQ29udGVudHMgMTYgMCBSIC9NZWRpYUJveApbMCAwIDcy MCA1NDBdID4+CmVuZG9iagoxOCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29s b3JTcGFjZSA8PCAvQ3MyIDggMCBSIC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwKL1RUMi4wIDE5IDAg UiAvVFQzLjEgMjEgMCBSIC9UVDEuMSAxMCAwIFIgPj4gPj4KZW5kb2JqCjIzIDAgb2JqCjw8IC9M ZW5ndGggMjQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AbVb247cxhF951f0 QlCWu7Ok2CRnOIPACSJ5vcHCiiRrbCfROi+LCEFgGVD0TfoffVKqL+dU8zozu7L0wBHZXVVddepU dZP6aN6Yj6YyVVnJn7qp2/XWms7uyp38Meu2Mv/7t/nZ/Gaevfhkzf0nY/3fT/cyad3EYR84I+O9 X3kvCm+qbtdsG/Mr1emd/5j3l05D7TSINfL30332UVS5n9a0TWm9Qe1uV3ZduzP3H8zzvSm83a3Z 35u29WPlYoP1ppDf+w/m2X5vS5tZs39v3pn8+dX5Xy9MYU1+fnVehV/1+WX48TRcnv8pXO8uwvXb cPlLuDy5yNz0Z+FfUcS1TP3F7G/N9d67dGx5sy27ddVFy+0mLM1dCrvJgqF16VYrhuafL8z+v0EY PA+/SMCWpGfiF5W+LjeVXW9qpyR6Q3wZlZz1lPScv6QkGzlf9dVdQFKiT7wf9In3v4mujJenF9nD nNZ2ZW23XddXwyC/vMsvBHaNyb9z19rkq4eGZ7sp113VNEmU0gU5xFSywPy5U9Sa/CpeHTy8BS/8 D3nCOw5sMifLC+eGqlybPN4yOeVxtAOYl8xHDp3+Dsd8K5D0cm7xiIMd2L0HOBgWcgg1xCFZ/ip6 TYZMxafbIR0l1VJQhxy07lLYrmzGuP7Sg5xnlAlcTynwuKaCruy2G+vD4vScBm3BSeCVKT2OV/wK JBVbU9fl2jFjXI8SSoR0lp/RfbXzmkCBUW0QDYbFM4qPFGcRqpIMEimZf+OnCSq+R+zOXjJYBSdS 6LFRinnrObN2nKnLtE1bbnby7xC20TJNbq8vZMm5aHeIyAY0d9iRQkJSUzo70hCS1gEfhKf8doTY jbhsU0Ns5NE0Q4/mgpGy6K/ES7u2XO9axzoJ6FJl82HKNLU1hOLTfmozSVdM8vM4Bml7CZiIrsXk bFytTCoOcwfJKVHOpDpq0fmiMVgoOvRTX0GmfnpUcgrKBskJPaN4HEpOZWVmYvBils+ysvQFw6Aw 4zQ6jHN9kfVzHrMLxOtgmMSfMUx9ikvC5JqYh4cpKhi57xFhSnozhYMu5BQOzaQt+HN0OUFfrOhh pcxxkRxmiU+y5aSYM3JXlbuqaheIRA0hIFaINoJNhAi+oh2Z67DHmO7b4TlZOr8+J9dl1zZJ6XHZ 2mObu4vLy0ZsEGJ+O4Mzts7NmjiT8GTasjmc7cotmmXF2eej6GCkADhjh5v0oImeo9rQBGcjPaNO Ouk9Ez1wmMPZy2G8WHzx4FgvxkXq/kP92TVlU299LZ0ww+1Bbq+Xaunhhe6k+mxr2Uv1AicLZQO8 R+eAnoTABFKTBYeuQ6tSbCySigUp7Gw0FyBHc4K6CyYsaxbNgEQVVJTeZoEyB1FmGpUEEko9zQYc 2qeeZQ4NXcxRpW5OwYBDY/9xFLYnaUH19IvB4VJ3g66R7vubY1XZA71yNUr2QCxJiJm4ddBxrgpS GnZOGByDkeXHUbMGllFEzCOKspxVma0slPHGW2+i7J5SCEx6zgYIgH2mup3HldE5BQMInLIVmcRy 1AN640KWIeDo7QwxY3ezkLB0MVEQgZM0RwspqXtXzi+oNv7IxrvhdcTkxHQYT/zSwnMHYMEAV0OV rz08BNu8cwlMU4ymgaRDLbvuWQocAFQyhtL4Awglpb1JTFhsPerdepmkRodAX44qwGTBREGfPB6B UPNxvFlO9Di2ndpPzmKVFcqKI4Xr67uL2/Dr6bNKgniCBwUTfmfea5q2tT/w2s5v0fobWX/ENpWG g0Xq5sZWrXSKXdKWxSNGWc7+vUtDYvGJh4YwMLH4Y2x0gSJyI+cobxJhxB75Ums1IAuBlDPIpiy/ 9cZIFmFomk1Tbrd2LVWj7vqorcPuzF0K25bbTs5lR8D9fBRwpxRklgrasq6s9Y6Oek6h1gS4U3qM 6rFbHln29aBzNO+yfOMCJzzzE7z4c7xBh8Otf/cjBNqspAxyDGSWa5CJDA6iwBWfLaAmHhkRIq+i WcrFlDdAhLShWEswPZvgV5oAzqQ02ot1Q3MckRFnHEl9rBMUrw7h6NU/KOm1N1S8z2VCKa7zZmk4 eL5GKcwAVU8bIXmG3idYcd0/4GfdXu5BhYBkh3hMD1rPKRjQ+2N70ERPv4zMkrpnPrex+eMwKdIC GqHKmIO61PkHtgChV11dx26AKEKoGFdBwwKh9V7EJHyTEFokmlO3wpFoogJ0oo8ntMy9Dkua3r4e NIrUs0RorL83PqfkkHmlXkdEmE3ujZenPd6xuIMoMF8L8IvG8wh5sURqp6iljeFUgYg0lbq9yEKo a+s7rlEkHhxqpn0MQVQwCsFRtSvDgbdk/9zLtwN6xqGO2a+1y+Sty0qJNLyHK7mO0aXLV4HvM+1c 6HIemXDWGCWUo6H7Lm5CmbUkX5hDeYCN7kWpM5KHwkUV/FNxTIqh0ZQ9fB2mkjgE6mmg6oCplKt7 4Vt/LJ+0V9jpYA7F0Tq6AkNQZNn5iU1T6NaOv2qWtxSPPeKvewp+vyN+6EGmsngerjnzZ8dpn0VE MszaITEO8P84Qlex5igUFJyUOJKDuOqJWODILP/B02i6pcXYQwcePB202xB7uIzHrY7ckoPHU4vY YQVf+TwXCwGJciGHz3NvUMQYsf5mf+nMi4jwZ17hgAElDMHQPJ9OxJGvZA39nsm99qyqzu1Hk5iQ nd1eEVVg4i2Blbeb7t0QYsy0ONhTykcox/SUswoGPeUpO6+p3TT0IMZcyHJ+u930u5nqxWxj/iF9 ET1WDcna+H2EBh2Dj6oaPAdD/kIFdROANItz+IhoohXckuhejxILcgSHUxJrCU8EZLMZIMz5wLJS FvXrLQyiHCxQxCxWHtsGZI4COkZmaDnzL4r0o5A5p2CAzMfudpKF9DN3GZlut/M9emHtWaP3E4If IYWoxBOGBTcITQb1FuWC0SU4rl16SCHhEzUGjyJsMvfxhrTzSY/CSa+xFIUGBxN+K4jOcvRIMLmL SUqBtBgjZtqhpMNk5mAK/DASHrtToy8Qoo3ycgKTaQBNks2pQvoUCEb2FdfJeaP/2HBXNvKn3vqz MP6j2cgL2816I1wvL4DwTZJy/ZX0iCD7hZaf3V0Czf5braaTl9XysaYoSj6yoqL0CJJO5am37J8D YkZufYEWlmxAlJFwFB+EBV/aw/Uhblk+UoCAksf4Q/vogsr15f4zb5ico0KAWsHVzJzTyNFE+Jok bKRs3S+o3DN/rR0hFIAXqeAr7whn9Ry1I7y7ixhgEBE7ZgvzB09CAuuxHiHBIBJrmIJwUSjVSQBj RSYdkm8wmxZwuoadg+OzTI8GCUfaBTMUZGQJPEIdZEEmCqmJ9ZwLp13fRG/iG9AzWkWXUN5DUypU dzqQunkHbtNVUietoF30LWbN0HPy6oJCMCX4LvlKgKZonOhoPhMTlIWnWt5KSPR3bXnnFAwai0e3 vFEPmOCElveVw5McdxPKfZfrSc4YBZxCziQKiFsGn9MBf+hZFRxTrAomBbGLcRTA4Xjyi28ohLKZ P+FJ8h7qLboRStFPaXmLuBl9maBMRBUKfdqDBC+wMaTkhB4GnTPmYC2kKMW1moXB2EckDQ3tSle6 CH55e6lfbCanLeOmOhy5n9pUR/mj7eRXhn5vGclXxssttdvsoa8kaOFeXBET+lZjrv2CVhcO+zFS tIaQjxheQgP5h7cXCceNM4WziDmfMvHLGgIlJmYCD65xITHnM25ijbSESkdJo9TB5cOByec4fEbL 4HZK5g8qVc+KxPiu5yUbjRuf7HII/QTEwInza4xKkg9SYAdwokpJOBhyO6IX91FpNGwIJ2JABXKF 3G0gxVkUkx2VrGYqs21lhcjdvkBKmvxvB/+/lvRbAt91xkIj7TtfzrDXGMKNTnvtVyc1Asvli+m4 lExfVXPScNV0ka56OCQ4uvfRF3rHP/wLHp7uvd/8H2HNU/gKZW5kc3RyZWFtCmVuZG9iagoyNCAw IG9iagoyOTU1CmVuZG9iagoyMiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9S ZXNvdXJjZXMgMjUgMCBSIC9Db250ZW50cyAyMyAwIFIgL01lZGlhQm94ClswIDAgNzIwIDU0MF0g Pj4KZW5kb2JqCjI1IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNl IDw8IC9DczIgOCAwIFIgL0NzMSA3IDAgUiA+PiAvRm9udCA8PAovVFQyLjAgMTkgMCBSIC9UVDMu MSAyMSAwIFIgL1RUMS4xIDEwIDAgUiA+PiA+PgplbmRvYmoKMjcgMCBvYmoKPDwgL0xlbmd0aCAy OCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBvVltbxw1EP7uX+FQFfZy3c2+ 3t5KFKSWa6sIVAIHRWpLkSIqhJpKIb8p/6c/ibF35hnv2neXnCjJh3W89sx4nmdevLm2F/balrYs Svqpm7rt1pXtq6EY6Md2bWn/+dO+sh/t2dObyl7e2Mr/3lzSpq7hZVfYYTD3AXMsvCn7oVk39gPU 6cxf9v2p01A7DWQN/d5cmmtS5YaVbZui8ga1w1D0fTvYyyv7ZGvb1i+gR7Muhr7sbU7j7ZU9226r wpm6fW9f22y1MGVR2+zXhc3LorXZqwVZRRMP/URlswd+0NjsTAa/uCW09Ct+lrL34cKQENrzhSz9 zQ9oZhktPpVXbxZ+1AUaWKJRKyq/huzS1RBQOztIR+PXkGF4gwHtcqYldPiTvrXbc7vZeshjz1bu tKNb69671T/yuio653szurUuHCDk1ux2Ybd/j/KEHAIdcWqfAqMKhqLt6lVDwIkeho8QZz0nEz0T ithrs0+PVT11PzI80qM0Mdnv4lqBsXM+J1LI34+YC/mbbPYGRBqXmgycSEBZeD2EJTgFeTM5bomD lOA+F+OeygBUVRUQuISgF345cerMS6LTyCmwRCbkmLBGBYNjy3GxyXKcAnZAO0lOka0fOIybdadk G2O4do+8bovBsS0i26cJCXwmSpAtpcB4yaWlR9UUTduvVqrnSLKl9DgFziR61HXRuXQa6QnJ9pi5 9J3Hh2IWLoY/AZDi8MztIjBBgrx2uc3lHuw/zvtVR9a1606NZhDUaJuJ0ZKMljJByg8jbji9qKPK VdEOq0p1JpI3vIAzP3JHppCAo/AGM3BGDv/2znXkZ8h797V3fWWy1/wqWgJ5y28k6iRIJGggjleY bMPI/iRbZKnCeC6vYCeJ2e/AjlwVOTAIGfac5ue9IYO8qVR2CqQAAKE7hYwJ6sAsP6MOHNATh0yC fU/YseJPgULYKH/Du+OE0Tw7XwnwFJoQkbHOM01c0HEuFkVIeCeo3JD4vYfY513XdFDexWoeGNQV Mctl7RQL0P80VMcA0qRKrwvqrxKJ8/ZOiTOlIF2lWc+RiTOlJ12lp3o0B5nsBAhhgJ5IgPmDmQI0 Wo5wBDTq6lZwAjxYIzyTpKslb9oYBB0cOkDUf63EsblaaLWfGFMb1k7S+shH2AeLkeM203NTlRZq yVM8BAUYwFdLKNAeeLQKCsNNewlbD0Gl/xyEDRR8VsIGeu5LWKmR55L0hT05/LmMO8qIwo+56oW+ HwkBMQLuS0cDSj07IdXUg726VkiEqipiY80/+oxImvQoOCUECvXAUk22IpmtMJlGi+ySIJSlkC8T OAEaUqr5fA8iG1L07KljcncaW6/qHfmUbz2U58zsMpkKD3I39SOwBI66kOTCzqCAnJ8HbooO9tZv DguHHJmXmixqWObSNcPg/gnjuJUn8ArvL2oiEfk4CswTPBRpvMqRf8k3zvNkc5wzIQA8wGCjaSuA S3sUwNUEPcokmyhc87s/H9foxRm8xgDHFvcdLMS1uy5LOzaxZFq4tB273VeIcVQUSK9A2jEoCK7L Uz3hdfku7dgBPcF1mfUk2jH0PBrP4FbOFLXZjmRHBYVYIoSOkh249dwHQfhJQ5gle/E9RrKeMlSz iQYtJGtxG6N3lGf0aoWVwgrR+N8FVQ4KIi/soh5yVtWvd1BvdxDgI4AcBYx/xp/GcNhjOgY+hcGn BYiXoBfXgSAYKHmQc8i/Iz3IqCAfxHeJqgvSN+4s00uRS98ahZ/2ReFdFcSXIo6OMArDj2MHL0XB QYLvFfGlKHE9jjpbJb3ck8X5ehdOZd6xl8hBBFBz5IzR4qDBJPACbwiGGMUXkJ9KuUHdEAsPAl43 Wq9TgDMQxwOuCgIgYsCPvP/gFlypnvt+OHoHZ7+ct3lITOJPhJRMSPwTKtwiCYT7AMO7+DMIv6LO DWbNEyuMgBixBm9QLXDFhjTlD1Yvf5ZOmiSmEgSq29DuSJXT6ql0ud2XH+Iq7eT/D0U6qeZ+NRr+ FN8jGoGKgqvsiFf9INeZB9KeYoB/iHwZAuTySnBD/pZ7PXxQ2/DEfE9wfQlhNhf/AvCMB0MKZW5k c3RyZWFtCmVuZG9iagoyOCAwIG9iagoxNTU1CmVuZG9iagoyNiAwIG9iago8PCAvVHlwZSAvUGFn ZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgMjkgMCBSIC9Db250ZW50cyAyNyAwIFIgL01lZGlh Qm94ClswIDAgNzIwIDU0MF0gPj4KZW5kb2JqCjI5IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAv VGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczIgOCAwIFIgL0NzMSA3IDAgUiA+PiAvRm9udCA8PAov VFQyLjAgMTkgMCBSIC9UVDMuMSAyMSAwIFIgL1RUMS4xIDEwIDAgUiA+PiA+PgplbmRvYmoKMyAw IG9iago8PCAvVHlwZSAvUGFnZXMgL01lZGlhQm94IFswIDAgNzIwIDU0MF0gL0NvdW50IDQgL0tp ZHMgWyAyIDAgUiAxNSAwIFIgMjIgMCBSCjI2IDAgUiBdID4+CmVuZG9iagozMCAwIG9iago8PCAv VHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIgPj4KZW5kb2JqCjE5IDAgb2JqCjw8IC9UeXBlIC9G b250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL1VFTFJQQitBcmlhbE1UIC9Gb250RGVz Y3JpcHRvcgozMSAwIFIgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nIC9GaXJzdENoYXIgMTY1 IC9MYXN0Q2hhciAyMDggL1dpZHRocyBbCjM1MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCA1 NTYgXSA+PgplbmRvYmoKMzEgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFt ZSAvVUVMUlBCK0FyaWFsTVQgL0ZsYWdzIDMyIC9Gb250QkJveCBbLTY2NSAtMzI1IDIwMDAgMTAw Nl0KL0l0YWxpY0FuZ2xlIDAgL0FzY2VudCA5MDUgL0Rlc2NlbnQgLTIxMiAvQ2FwSGVpZ2h0IDcx NiAvU3RlbVYgOTUgL0xlYWRpbmcKMzMgL1hIZWlnaHQgNTE5IC9TdGVtSCA4NCAvQXZnV2lkdGgg NDQxIC9NYXhXaWR0aCAyMDAwIC9Gb250RmlsZTIgMzIgMCBSID4+CmVuZG9iagozMiAwIG9iago8 PCAvTGVuZ3RoIDMzIDAgUiAvTGVuZ3RoMSA3MDAwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0 cmVhbQp4Aa1ZeXgUVbY/997qJRvpBMjaSVfTpJF0YiCAAZJJOksHnIgECNqNQTqESIJgImFTEZpR BNoFdZRRXHAZBXWUSgeZDuAQRZ0RRXjq6LiC6Aw63yDo96mjYur9bnWD4PjN++fVze+cc885dzt1 6tatzpLFS9somUIkyNu6qKWLjCv7M7Cu1mVL1Fg9JYvI3HRF1/xFsfrghahfNX/hNVfE6jlB8Gfa 21rmxep0CvyCdihidTYWfHj7oiUrYvXsD8CTF3a2xu05ftSti1pWxMcnaVevalnUFvPPHS/rXZ3d S+J1G/h5XYvb4v4M7ZP+5J2Qd71EzGcQEYMk6CuqoAfIQpxsVEKXECl/UPLIhLq0m1Kbf7tr6/g5 qRVfW3OtRtNHPhlRKIWX7pt76ffbf5xvI2syqgmGvzSgnaVy4GKqtdH327+/FpORPZ19iT5qEuf1 urMch/aIkXQE4GJkxJPn6BMjRF6k3OGNCldv+tDS1OpioaJ9iUFV0E5gO7AXUGiOyIfVBroaCAHb gb3AIcCMBeYbVhW8E9gCHAHMIk/YI6rDVj1CZKNtNtabKjLpBKADghygJcBUYA6wEdgCmA0/qekE VgN7gZOAmbwiM3LnGMw9M3KzwXoXLCw1qi2xavNso9p7aSDGp0yL8boLY24TY26jx8bU59fE+Iii GE8vKA2h897ElNL+6gyRgUVmYOJdoIy/SKmMkYMeEkNJA7jAVA2NV6T3DneXbtkrFGKCC0bzyKH3 CxZJSSutTuQ6P0Hp5OBf8OMxCz/eOyitdEv1r/lR2g7sBQQ/ivIx/5hW8yMy5qBVwBZgL3AQOAGY +RGUwygf8Y8olX9IJUAVMAfYAuwFTgAW/iGojX8g88OgUq4COP8A1Mbfx7LeB03l70F6j7+n9/M3 I2UTSvsMwVMSFxwFcSEzNy6kZ5RG+RuR70Yio9y408io3WIYVdIYMSxSMNoRFVmRig5HlH/Sq3oc D1WP4m+RBnDM5C2M/BapQCMQBLoAM6S3Ib1NIeB24CFAA5BloDZA5fuB14C3aRTgBRoBKz8UwTBR fjDirnFUZ/DX+Z8pExE/wP9i8Nf4ywZ/lb9k8FfA82Hfz1+O5DuoOgl2QhsbuA28BHYTf753eLpD r07jexFBB2gJUAVMBeYAGwEz38uHReY50tHJbtqPZ9jBI/S5wR+nR6zkXeDwumuRgKok7om/ggSy Rd3i5l73pntRlcR9252QJHHfeAskSdzXroEkiXvhMkiSuOctgCSJe9YcSJK4pzZBAonyB/84fISj bOqVTK1O5csRpeWI0nJEaTkpfLks9J0i53hfpLAQEdvs9YwsdIR2sdAeFprOQo+wUBsLrWKhNSxU wUKXs5CHhewslM9CXhbazcYjFCHm3XFOdYI3i4X2s9DTLNTNQm4WKmCh4SyksjJvlDsjF+KpA/MZ rLdaPnTc2furSuw+qdyJiDqR807sCXtBDwK6UfPCSR0Wc87Ol3xYb2FVrH7+xNLO6sl8Hxruw23Y R4cBBTdoH9JoHzrZh+5SQauAOUA/cALQATO8h2EdGw2aCloCVAFzgNXACcBsTOcEpsKpE1ROcbsx sRLQKmCqrPF9KMNQnNzpzbPZbR7bZLHRzlLz2dR8PZ+XUUYG9ub0NGtalKXs/Dbl39+mUEJ1Ar+N b6Q83Ijb43xj5Ls8R5TdE3HvdlQPZb+jfAVZxyaQmxWAj6duoz6O7FapH0t2/hR4acR+CZqlRtxF jl1skGy10/Gd/VPH5/Yoh/iZfbfjHTWqsIjjr9A8tdPxln2D45WSqBWaPe4oA9ulGq599vGOp/cb rmtg2BxxrJJsp+N6+yTHlXbD0BYzXN6NmjfVMd09yzEZ/dXZ5zq83ehzp6PKfrmjIuY1TrbZ6RiF KXhiYiEmO9JuDOrKNzqcWRZl7d4iyyaL3zLVcoGl1FJkcVocljxLrmWINd1qsw6yJlsTrVar2apY uZWsQ6L6Ea9HvvWGmI2XnxkJzUgxZBt2GCa3GVDizMrp16QNFg28YUYNa9D6W6lhrqp9M8MVZYnT ZmkmVw3T0huooalGG+9piFr06VqZp0GzNF7m72HstgC0Gl8fZdTkjzJdqtbmaum1/j5iLG3trbmS n7f21kCAsjKWVWVVpVemTaiv+wUSNJTBOs9PV9ZPoifLk6dtapjh157MC2ilUtDzAg3ab2eozf4+ 9hU76avrY19KFvD3iUr2lW+61IvKukCgIcouMfxIZV/CDxkDBj9rPqnSj1Rrfsxvc8yvAO3hN1wy +CUkUIHhV5CQYPgpTPr1dA/31fUMB4FPpkrdhk93pnq2z/4C+BSAwCcjRPsNn/0ZIemjVRrd2O1w yQeBC8shu+FiZzmGizHzHsOlJO6y4YzLBmMkEZuN4SMJukk5cton5Qh8zgrkfxfbajwe1lseaG32 tbl8QZevDQhqNy9rz9JCc1W1pzUgDaom3MG5re2St7RpAVdbndbqqlN7yo12PzM3S3O5q66Hmn1N /p5mb1tdpNxb7nO11AV6JzWOLTtnrA1nxhrb+AtjNcrOxsqxJhntfjZWmTRPkmOVybHK5FiTvJOM scjI8UZ/j5VqArW4f5L38qRE5Gsw1xmoybB1VRrJW+7MWpW7C6eVbZTkCWjJrhotBZB5XVxdXC1N eKakaRDUqXFT1qpyZ+4uti1uskGd5qohz5Kl3Uspy9dRF/vrxgXVkqXyVsSoR+p+8YKLT/O21Mmz dYNWOKNBq5o2y99jsUAbrAtAN/G0LinJF9X7Y8rzoZwoHYU44yh1FVKXkBB3/M9cMOYENaLTh4PG 7l7mzWdLqDsgtPyGJo6toGkWwtA8y78LZyn5kugOYIHdzMO6T/cm12HIFNMQlt19GkuWxqV4LJbE ueHa7SFP9+mQnO7OI4NlECNWSzzY2ky7KBvIMW2lbMVNWUT6MQDfRfqxgQ79M2mXnP8TG100DqJt 9DTroKdpL73ATqLVduqjHSSPQHV0P62ku2gdXmuzoNlA01FM0N/FsvUd+DJ5GC/Mh+kAfC+lVbSL MliW/jmtprXiTbRaSyk0jKqpkTrpVnaRvpSa6bByA5XRRXQVdbGQ7tdv0+/Uf0+PUZ/4i/4jJVEO taIc0L8w/U3/gIrR4m66lw6zOxOeJS9GCcHzAVpMm8Vshenz9e8xAyctxxwUmkIHWD/3oPc2Osay 2EpRi14e1TX9RXjZaTa102baxcaxSdxpatan6AcoA2OsQK/3UoR2okTpOXqPJZtO6r/XT1I2FdGF WM8Oep31i4Ef1wxUIW4mRGkkTYClk/5Ef6ZDzMWe552mZFOpyWu6Vn+LhtBomonZbkXLf7Bv+SqU 1eJlpV6voUGIyx0y2vQSfcxyWAmbyi7hI3knf1AsJitGHI0yjzoQ73vQ+0dIo508mR8UjypPKT+Y 8waO6INwR9x0Hz1Az7MUrFRl3ew37G32Ca/lc/h9/Ki4S3lCecPSglVfTovoVnqKvmXpbDybxi5j 7WwlW8fuYPeyA+wQ+4xX8yZ+JT8h2sXV4jmlBmWG0q3cYLrJdLP5swH/wIsD/zPwrV6q30TTkA9r MPu76UGsrI8O0rsoh+koM7EkNghFZU42k12Hsordyh5h29gTbAdGOcSOss/xSvqa/cDxpuVmnovD jzwCufhinDDv4vfzgyiH+L/4dyJTDBMeMU5UiIDoxKzWidtRnhUfKznKQUVHnEtNm0xbTNtMT5le MJ00J1t+g3f8a6ce/bHwx48GaGD9wKaByMAO/WMainuItwc+wSow+xaUBbjfm5Bx2+lNlozY5bBC VskuQmTmsAXsarYCkbyRbWaPGXN/hu1BlN5hJzDnFG435nw+H8dr+FSUy3kbvxqHsTv5Dv42/15Y RJJIFUNFoZgkZos2sURcIzYJTbwmPhRHxTfiFIquJCoOZZjiVjzKJGWOslR5UDmmHDM1m141/d2c aF5kvskcNX+JU02lpdEyzTLbstGy0/KWNYjs3EfP0h+RgWcudkSsET7xLN3GxyjZ+IR5Hfk8h+aJ KRyZyrex9fx6toMPN60wl/NydjGdVNyI9ct8C/+Gl4sprIHNoAV8dKxD8xDlSUgVyj46ruzB2l5H zyvMyWwVP2FOpgjOSBNwRnpJjFI84lV6TxxmFuVhel9JZJnsON8qGpEFzymVJj85xf30jLiaXU/P ch9R4g/WW5DHF7MnsS80sVL2b6HjGHwxsqhMfEI30JX8b3Qcz/F6+h2bp8yn22gMW0nH6HE8FSNN V5kLzUPZK7xDCfPBbAdx5QmsbgIbzoRpCN3IZovN5hP8XVpKB5VE+kj8AbM/yJ8RU5STpumsHU/A 9XQTXa2voWtMfuUNNp8Eu4QKlCPY3VaKUsUJvhq7SjP2tJ14undhH6gWU6DJQuZchLyYiR1iM8o9 2CcUZFAHnvFLsYu9TjvMTTxK802DGHYd/FLz6sB0mqU/Tvfq8+kq/U4qxn6wTl+JHrfR32kjbWNr B66jLnxKvotn+yJTPT9oqteLeZi/y2fwTefeX0S7gGXRP1GewZ2pNO2msPIOzaAq/Rb9r8ju87DD 3ktzcWD9FKv8AiNMFv00ZuBi3qPXiy6s9zBN07fqDpZI7fpCmkp76DGLiVosHtxjjb2B9V5HbXy6 vkS0DXQgDhsRBS+itRT7zwZv7cymam9V5a8qyidOGF82buyY0tGjSs4vLvIUjjxvhLtguGuYU3Xk 59lzc7KzMjOGDhmcnmZLHZSSnJSYYLWYTYrgjIp8rvqgqrmDmuJ2TZ5cLOuuFihazlIENRWq+nN9 NFW2a4HpHE8vPK/4mac35uk948lsagVVFBepPpeqHahzqVE2a5of8q11roCqHTfkKYZ8uyGnQHY6 0UD1ZbXXqRoLqj6tfll72BesKy5iPUmJta7atsTiIupJTIKYBEnLdHX1sMxKZgg80zexh5M1BUvU clx1Pi3bhaboRhT4WuZpjdP8vrpcpzNQXKSx2lbXXI3kScljuFCtMYxmrtUsxjBqB844Gt2s9hT1 h2+J2mhu0JM8zzWvpdmviRb04dPSPBi3Tsu89tOsn6roHGeydWdbc0XYl9WhSudweJ2qPTTNf1bb XKfsIRBAH2jLC+qD4XoMfQvuVIM8i2t8bcCvsbUYEgfLAmNVsfXFTr0FwQWqluCqcbWHFwRxa3LC Gk2/xhnJyfH26Ucox6eGm/wup1aV6wq01Nl7hlB4+jW92V41+1xLcVGPLS0W2J5BqXEhOeVsoQ1B j9kMyXCXUsP0M5Flco6uC3ES1NRWFTPxu7Cm8ZK0jadw63jcAFwBhlbaPNyRDi2hNhi2TZR6LJFp pgKbSw1/TcgA1/F/natpiWvMBbavSRplnpxJNY21nJY1j0crLJQpYqnFPcUcK436uOKiZVHucnXZ 8P0sPxqoEbFtCUwsQfidTnmDb456aS4qWmiaP1ZXaW5uhLwlOFvzoLT0n7YMnSktodOWM82DLmTy Dvk9S0M1q/vMX6otY7CvfaLGMv6LuS1mb5jhasDRWPWFg/GsbWg6pxazy4AibrDFJW1wrV/kcuik xHOFYY2dkE+74LjsT9aUAvyZjaSeF7VYkZWGhqn1mi04OUYDiU5n/Jn5vxpF9ZOylcF+ahZfhjbR E59obNpa+Tn1c6aXHBYNTdhyOE724XDiOTakWmyWF8YZMh4f+k61VqOZeDIL8IdPjvESgVzNi5DB 0oSnyFAHcuPVcxxz440CuGR2FhfVY88Mh+tdan04GG6J6qG5LtXmCvfxF/gL4S4fdrtY4kT1XTfn avW3BBCxdjYRjwenmh4XWz+tx8vWz5jl78NPHOr6Jn+EM14brAn0DIfN36cSeQ0tl1qplC6qrFAD wyIj3Gr45/Z5iUKGVTEURr0Vv24YupgTdIxaozyms53249ApMZ3X0Mn1yT2mtskfvy1GQshHDzmE /9CgG36AFinduvx/DEORVzIMc8Efw+k4pjHU/4+EG30NpXK81fHKkod8k/xPjIXImeZMKwDBr0V0 ShX9p7wm+oFUpV/ObxE7xNtxFkoiRx8OFTO8gxLMr6k0CmfcpcmXbs3y2L6ZfZxKjo8eNXjsBWNK 8YY0u4a5F93d3nH33R3td/PXO+66qwMy+tJPsf1KJ78Mo+Z7U9k44jkmFUNkK73XZnkutn062/YP KpmCrsQ451BF6Wb777hDTjs2d9JH4Fz7S5eAch3OLXK+6fH4mfEdQjN9F01vrPFUL+5oWTil6X8B h6gdxwplbmRzdHJlYW0KZW5kb2JqCjMzIDAgb2JqCjQ2NzMKZW5kb2JqCjEwIDAgb2JqCjw8IC9U eXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL09OQ1VKQytDYWxpYnJpIC9G b250RGVzY3JpcHRvcgozNCAwIFIgL1RvVW5pY29kZSAzNSAwIFIgL0ZpcnN0Q2hhciAzMyAvTGFz dENoYXIgOTYgL1dpZHRocyBbIDI1MiA0ODggNDg3CjQ1OSAyMjYgNTQzIDQ5OCA0NzEgMjI5IDM5 MSAzMzUgMzQ5IDQ3OSA1NTcgNTI3IDUyNSA2MTUgNDIzIDUyNSA2NDYgNDUyIDUwNwoyNTAgNTA3 IDUwNyA1MDcgNTA3IDY2MiA1NzkgNTI1IDg5MCA2MzEgMzg2IDUxNyA1MjUgMjI5IDQ1MyA3OTkg NDU5IDMwNSA0OTgKNTI1IDU4MyA1MzMgODU1IDYxNiA3MTUgMzAzIDMwMyA1MjUgNDYzIDMwNiA0 NTUgMjUyIDUwNyA0MzMgNDk4IDM5NSA1MjAgNjQyCjUyOSA0MjAgNjIzIDI2OCBdID4+CmVuZG9i agozNSAwIG9iago8PCAvTGVuZ3RoIDM2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJl YW0KeAFdlM1q20AUhfd6ilmmi+CxRmMnIAQlJeBFf6jbB9DPKBXUspDlhd++37k2KfHiMxzduTPn XMmzetl92Y3D4lY/5mO7T4vrh7Gb0+l4ntvkmvQ2jNk6d93QLjdlz9pDPWUrmveX05IOu7E/urLM nFv9pOW0zBf38Lk7NumTnn2fuzQP45t7+P2ytyf78zT9TYc0Ls5nVeW61LPd13r6Vh+SW1nr466j PiyXR7r+r/h1mZLDER3rq6X22KXTVLdprse3lJXeV+Xra5Wlsbsr3Rqavv1Tz1mZx4rF/tnx0/GT e35qb523NXcdsVBHrsV153K//rA4+quhpr85yddVKbwvnivOy5GAjJIBCd6zLZK9BdWN5AYJVHPJ LRK831jvExKQW1WfkYC0g2pkI7kNqrZIQNpWHRJYvFa1RwKyRwamJ5BJEvsCVzIZsC+oaueAfcHO chWwL1hsvcw32Iy3ShRII7xnDZI0gnm2kqQRVGUykCYQA8mMy0AagbRzSRMsUWGeSRMsUaFEISEB k0+ShBNMUrMqCCcwaZJwdCEZAlXCCRbr3IJwgoAmCccckBt55jUaVDV23ptBtZMknGAreS4IJ6hq GnwRBuc2kmQVVDWcgqyib/iakWQVeLatyFpc89pBhGMOVLdKhPEyXhMpPp+Pwc4aLF4MJqm8kQiC qmxEIghc6Q0yMIPFer8R+4KDbGciRPvq8vr2p7l++Nu7/0EkmKCPhWUkmCCNnUmwaOEwQpVgguh6 mZEXKViskUdyCqQsbMgqMPjRgv78uqTeL5X2PM/cJ3aT2VWjK2QY0/tlNx0nXRnGPyJhS7sKZW5k c3RyZWFtCmVuZG9iagozNiAwIG9iago2MjAKZW5kb2JqCjM0IDAgb2JqCjw8IC9UeXBlIC9Gb250 RGVzY3JpcHRvciAvRm9udE5hbWUgL09OQ1VKQytDYWxpYnJpIC9GbGFncyA0IC9Gb250QkJveCBb LTUwMyAtMzA3IDEyNDAgOTY0XQovSXRhbGljQW5nbGUgMCAvQXNjZW50IDk1MiAvRGVzY2VudCAt MjY5IC9DYXBIZWlnaHQgNjMyIC9TdGVtViAwIC9YSGVpZ2h0CjQ2NCAvQXZnV2lkdGggNTIxIC9N YXhXaWR0aCAxMzI4IC9Gb250RmlsZTIgMzcgMCBSID4+CmVuZG9iagozNyAwIG9iago8PCAvTGVu Z3RoIDM4IDAgUiAvTGVuZ3RoMSAzMTM5MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0K eAHVvHl8lNXdNn7Ofc++70sms2WSmYTJnpANSAayEwIECCRAgLCDILvsirui1l2Lu21dsZqELUir 2IfW2hZrrUs3rT5dtLa02lWFJL/r3GdOCKjP+34+v3+eN3DNdZ1zL3Of79m/59yzdfO2FcRI9hGZ FC9b37uRKH/lz4C+vuyyrREezllNiDpz5cZV63l43DWE6DNWrdu5kofH/4SQhoHVK3qX8zA5B65Y jQgepuXg7NXrt+7g4bJHCKGmdRuWpY+Pb0D8Det7d6S/n/wG4cilvetX8PN37WPhjZtXpI/TLtzO dmHY+EKqOriXgV9jwVdA1dMIsZH/IloigYsI7mi/jV5FVDjKjqsfGrzlPz+2L7ZO/Bfx65RLT/x5 D9JDyMvXP3nT2c+HbtL/RXsUQT3uwP9wnfahoV8RYnjk7OefP6L/i3Kn9EGF6gf0cmRQuuaw3ken QlwtxFVCXCnEPiGuEOJyIfYKsUeI3ULsEmKnEDuE2C7EZUJsE2KrEFuE2CTERiE2CHGpEOuFWCfE JUKsFWKNEKuFWCXESiFWCLFciGVCLBWiV4glQiwWYpEQPUIsFGKBEPOF6BaiS4h5QswVolOIOULM FmKWEB1CzBRihhDThWgXYpoQbUJMFaJViBYhmoVoEqJRiAYh6oWYIsRkIVJC1AlRK8QkISYKMUGI GiGqhagSolKICiHGC1EuRJkQpUKUCFEsRJEQhUIUCJEvRFKIcULkCZErREKIuBA5QmQLERMiS4io EBEhwkKEhAgKkSlEQIgMIfxC+ITwCuERwi2ESwinEA4h7ELYhLAKYRHCLIRJCKMQBiH0QuiE0Aqh EUIthEoIWQhJCCoESQs6IsSwEENCnBPirBCfC/GZEJ8K8R8h/i3Ev4T4pxD/EOLvQnwixMdC/E2I vwpxRoi/CPFnIT4S4k9CfCjEB0L8UYg/CPF7IX4nxH8L8b4Q7wnxWyHeFeIdIX4jxK+F+JUQvxTi F0K8LcRbQrwpxBtC/FyI14X4mRCvCfFTIV4V4rQQPxHix0L8SIhXhPihEC8L8QMhvi/EKSH+S4jv CfGSECeFeFGIF4T4rhDfEeKEEM8LcVyIQSGOCXFUiCNCHBbikBADQvQL0SfEc0I8K8S3hXhGiINC PC3EU0I8KcQTQjwuxGNCfEuIbwrxDSEeFeIRIR4W4iEhHhTiASHuF+I+IQ4I8XUh7hXiHiHuFuIu Ie4U4g4hbhfiNiFuFeJrQtwixM1C3CTEfiFuFOIGIa4X4johrhXiGiGuFuIqIa4UYp8QVwhxuRB7 hdgjxG4hdgmxU4gdQmwX4jIhtgmxVYgtQmwWYpMQG4XYIMSlQqwXYp0QlwixVog1QqwWYpUQK4VY IcRyIZYJsVSIXiGWCLFYiEVC9AixUIgFQswXoluILiHmCTFXiE4h5ggxW4hZQswUYoYQ04WYJkSb EFOFaBWiRYhmIZqEaBSiQYj6Q2y0jFHzQKg2jDHzQMgNuoqHrhwI1SC0j4eu4HT5QMiEyL08tIfT bk67OO0cCE7GKTsGgvWg7Zwu47SNH9vKQ1s4beaRmwaCU3DBRk4bOF3KT1nPaR2nSwYyG3HmWk5r OK3mtIrTyoHMBpyygoeWc1rGaSmnXk5LOC3mtIhf18NDCzkt4DSfUzenLk7zOM3l1MlpDqfZnGZx 6uA0k9MMTtM5tXOaxqmN09SBQCvS0MqpZSAwFaFmTk0DgTaEGgcC00ANnOo5TeHHJvPrUpzq+HW1 nCZxmsjPnMCphl9ezamKUyWnCk7j+c3KOZXxu5RyKuFUzG9WxKmQX1fAKZ9TktM4Tnmccjkl+K3j nHL4PbM5xThl8VtHOUX4dWFOIU5BTpmcApwyBjKmw1h+Tr6BjBkIeTl5eKSbk4tHOjk5ONn5MRsn K4+0cDJzMvFjRk4GTnp+TMdJy0kz4J+Jb1cP+DtAKk4yj5R4iHIiCtERTsPKKXSIh85xOsvpc37s Mx76lNN/OP2b078GfHPCg/SfA77ZoH/w0N85fcLpY37sbzz0V05nOP2FH/szp4945J84fcjpA05/ 5Kf8gYd+z0O/46H/5vQ+p/f4sd9yepdHvsPpN5x+zelX/JRf8tAvOL094J2HpLw14J0LepPTGzzy 55xe5/QzTq/xU37K6VUeeZrTTzj9mNOP+CmvcPohj3yZ0w84fZ/TKU7/xc/8Hg+9xOkkpxf5sRc4 fZdHfofTCU7PczrOaZCfeYyHjnI6wukwp0MDnjokemDAswDUz6mP03OcnuX0bU7PcDrI6ekBD1p9 +hS/y5OcnuDHHuf0GKdvcfomp29wepTTI5we5jd7iN/lQU4P8GP3c7qP0wFOX+cX3MtD93C6m9Nd /Nid/C53cLqdH7uN062cvsbpFk438zNv4qH9nG7kdAOn6zldN+DuRdqvHXAvBV3D6eoB90qEruJ0 5YC7E6F9A250NvSKAXcF6HJOe/nle/h1uzntGnAvxyk7+eU7OG3ndBmnbZy2ctrCb72ZX76J08YB 9zLcZQO/2aX8zPWc1nG6hNNaTmv4das5reJPtpJfvoLTcn7mMk5LOfVyWsJpMadFPNE9/MkWclrA Ez2f37qbf1EXp3n8cefyL+rkd5nDaTanWZw6BlwpJGzmgIuZdcaAi1XY6QOuq0HtA64C0DR+Shun qQMuDCRoKw+1cGrmkU0DrstxrHHAdT2oYcB1Bah+wLUPNGXA0QSazCnFqY5T7YAD4wI6iYcmDti7 EZrAqWbAzupRNaeqAXszQpUD9i5QxYB9Pmg8P1bOqWzAno/IUn5myYCdJax4wM4apCJOhfzyAv4N +ZyS/GbjOOXxm+VySnCKc8oZsDMrZXOK8Xtm8XtG+c0i/C5hTiF+XZBTJqcApwxO/gFbD+7pG7At AnkHbItBHk5uTi5OTk4OfoGdX2DjkVZOFk5mTiZ+ppGfaeCRek46TlpOGn6mmp+p4pEyJ4kT5URS I9alYYZh67LwkHV5+Bz0WeBz4DPEfYq4/wD/Bv4F/BPx/wD+jmOfIPwx8Dfgr8AZxP8F+DOOfYTw n4APgQ+AP1pWhf9gWR3+PfA74L+B9xH3Hvi3wLvAOwj/Bvxr4FfAL4FfmC8Jv20uCb8FftO8LvyG OR7+OfA69M/MyfBrwE+BV3H8NOJ+Yl4f/jH0j6Bfgf6heW34ZfOa8A/Mq8PfN68Kn8K1/4X7fQ94 CUiNnMTni8ALwHdNm8LfMW0OnzBtCT9v2ho+DgwCxxB/FDiCY4dx7BDiBoB+oA94zrgz/KxxV/jb xj3hZ4x7wweNl4efBp4CngSeAB4HHjMWhL8F/ibwDVzzKPgR4yXhh6Efgn4QeAD6ftzrPtzrAO71 dcTdC9wD3A3cBdwJ3IHrbsf9bjNMD99qmBH+mmFV+BbDY+GbDU+Er5VzwtfIVeGraVX4qs59nVce 3Nd5RefezssP7u007qXGvYG9bXt37z2499d7Uw6NYU/nrs7dB3d17uzc3rnj4PbO56XryErp2tTE zssObutUbXNt27pN/uc2enAbbdhGi7dRiWyzbYtsk01bOzd3bjm4uZNsnrl53+a+zaoJfZvf2yyR zdQwOHLy0OZAqAmc2rPZbGva1Lmhc+PBDZ2XrlzfuRYPuKZqVefqg6s6V1Yt71xxcHnnsqqlnb1V SzoXV/V0LjrY07mwan7ngoPzO7urujrn4fy5VXM6Ow/O6Zxd1dE562BH54yq6Z3TEd9e1dY57WBb 59Sqls7Wgy2dzVVNnY1IPMm0ZUYyZRt7gOmZeBISoFOKA6nAe4GPAyoS6AucDMgOa0Y4Q8qz+mn9 DD/d4L/Cf6tftvp+6pNSvrz8Jqv3p97fev/mVTlT3rzCJuKxeSIe2c3S5mmfw9J2yFPXwLlkvJLW dk8s3mR1U6s77JYaw25K7O/ZP7bL7hdtP7VJViu1WkesUsqK062WsEViHyMWOWUpqWyymsNmiX2M mGVPyowY9vAJ08w5TVZj2Ch11hlnGKWUsa6+KWUsKG4iMo1QrPzYQLKOPQ11h5sGKTnkoWo6SG/r nzM7mWwb1JFZbX26mQv66A19ObPZZ6pjfp/mhj7SOX9BVz+lX+vup1L9nD5XW8d8Hr72llvIlGBb X3B2V98jwe62vn0QKSZGIEiw30OmdCcXbdm2JZncuggfi7ZsTSr/EaLbWAh/OID/W7YizP6BECbs yFf/8dNw3uIt+FNuw+/+1Zf8P3CE/j/wjP/LH7GfoIh2TR6RriHLpauBq4ArgX3AFcDlwF5gD7Ab 2AXsBHYA24HLgG3AVmALsAnYCGwALgXWA+uAS4C1wBpgNbAKWAmsAJYDy4ClQC+wBFgMLAJ6gIXA AmA+0A10AfOAuUAnMAeYDcwCOoCZwAxgOtAOTAPagKlAK9ACNANNQCPQANQDU4DJQAqoA2qBScBE YAJQA1QDVUAlUAGMB8qBMqAUKAGKgSKgECgA8oEkMA7IA3KBBBAHcoBsIAZkAVEgAoSBEBAEMoEA kAH4AR/gBTyAG3ABTsAB2AEbYAUsgBkwAUbAAOgBHaAFNIAaUE0ewacMSAAFCFlOEUeHgSHgHHAW +Bz4DPgU+A/wb+BfwD+BfwB/Bz4BPgb+BvwVOAP8Bfgz8BHwJ+BD4APgj8AfgN8DvwP+G3gfeA/4 LfAu8A7wG+DXwK+AXwK/AN4G3gLeBN4Afg68DvwMeA34KfAqcBr4CfBj4EfAK8APgZeBHwDfB04B /wV8D3gJOAm8CLwAfBf4DnACeB44DgwCx4CjwBHgMHAIGAD6gT7gOeBZ4NvAM8BB4GngKeBJ4Ang ceAx4FvAN4FvAI8CjwAPAw8BDwIPAPcD9wEHgK8D9wL3AHcDdwF3AncAtwO3AbcCXwNuAW4GbgL2 AzcCNwDXA9cB15Llk/fRa6CuBq4CrgT2AVcAlwN7gT3AbmAXsBPYAWwHLgO2AVuBLcBmYBOwEdgA XAqsB9YBlwBrgTXAamAVsBJYASwHlgFLgV5gCbAYWAT0AAuBBcB8oBvoAuYBc4FOYA4wG5gFzARm ANOBaUAbMBVoBVqAZqAJaAQagHqy/H95M/2//fG6/7c/4P/y5/MtXsR2DBEyfOfYTUJkJllLtpB9 +HcduYXcSV4kvyZLydVQB8gj5HHyFOkjL5FXyNsXXPX/MzC8U72emORjREOchIx8PnJm+HFgUG0Z E3MnQk5V5HzMiG3krxfF/XX4zhHb8KDGQQzKtWbpddztH3Ro5HP0rxpiHqlgYel6aKvyTZ9oHxp+ bviJCxIwk3SQ+WQBWUh6yBLSi/QvJ6vJGljmErKOrCeXKqFLcWwV9EqEFuMstCWKPn/WBrKRbCCb yVayjVyGfxuht6RD7NgmJbyNbMe/HWQn2UV2kz1kb/pzuxKzB0d2KbE7cORycgVy5kpylaIE85ir yTXkWuTa9eQGciNy7KtDN46etZ/cRG5GPn+N3Eq+St9ywZHbyG3kdnIHysNd5G5yD/k6ysX95IGL Yu9V4u8jD5GHUWbYFXcj5mFF3UPuJd8hPyBHyLPkOXJUseUy2JZbRNhlpWLpjbDBHqT56jFPzK25 fdRal8MaLN370+neAftdNeaKy9J2ZNa7Gmcy6+xP5wO7y950jLDEbUgZ1+fTyWzE0nDrBekUV/yf YlmKmZ0egL2EZZjN7kHcfV+IHXvGWH0PeRA18FF8Mqsy9Q1orh5W9Nj4h0bPfUQ59k3yLfIY8uIJ wpRgHvM44p4gT6JuP00Okmfw77weq/jRZ8m3lZzrI/1kgBwih5GTR8kxMqjE/0/HnkPbcfE1h9L3 Ghi9y3HyPDmBEvICOYmW5nv4J2K+i7gX07GnlLN4+HvYS3lKOYsd/R7K1stooX5Efkx+Qn5Kvo/Q q8rnDxF6jbxOfk7epmaon5E/4XOIvKb+PbGQydh4+Txy4wGyiCxKNS9fvKhn4YL53V2dc2bP6pg5 Y3r7tLaprS3NTY0N9VMmp+pqJ02cUFNdVVkxvqiwID83npMdywr7XHab1Ww06HVajVolY2Sb3xhr WhLpiy/pU8VjLS0FLBzrRUTvmIglfRFENV14Tl+EXdeLQxecmcKZKy86M8XPTI2eSW2RiWRiQX6k MRbpO90QiwzS+R1d0Lc0xLojfWcU3a5oVVwJmBGIRnFFpNG3uiHSR5dEGvuaLlu9v3FJQ0E+7Tca 6mP1KwwF+aTfYIQ0QvXlxjb209xaqggpt7GmXyI6M/vaPjmnsXd538yOrsaGQDTarcSReuVefZr6 Pq1yr8iaPjwzuSnSn39y/82DNrJ0SdK0PLa8d2FXn9yLi/bLjfv3X99nT/blxRr68nb93gcDrujL jzU09iVjeLC2WaNfQPvUObZYZP+/CB4+duYveOoxMb3pGE2O7V+EHWRJHDVTH+0VmuDZ8IRIXzTK nuWmwRRZikDfvo4uHo6QpYEBkipKdvdJS9iRk+KIu5Md2SeOjF6+JAbLNsYal6T/X7ba17dvaaQg Hzmr/M/pU+XgeKRPji9Zumw1494V+2MNSCFsSebAadMAkepNG7Oxv7gI5/cuQSLWMDN0dPUVxTb2 uWJTuLURgZvkNK6Z3aVcwmMb+1z1fWTJsvRVfUWNuBZFpHE/yxj2gOxesY6u46Rs5L3+8kjgUBkp J93sOfo89ciUeOP+ruUr+8JLAstRPldGugLRvlQ3zNcd61rRzXIpZuvLew9fhz9koHIV0nbR2eJk JLtPm6OLdEkBuZvlFiIiTfiITZmIA7Y+DQ+yHJ0yMdJFA0Schm9Jn8HUBfdBQM6pb8HFYFxa3xKI onArf//DIwV4AvAYfbrRZ1LhIdTnn4l/z1c+Gj+bPVBepHFFw5gHvOCmCCgPmL7blz+nxGyRNgYe Qceys4WloSBfgo7gsK5PQjqVKJaLvkgfmRnpiq2IdcdQhlIzu1jmMFsr+ds2O8Ycg0pup0vJnAtC /HgVP9ZHom1zukSA+Wz6mpJKvrJsVcLNSng02HLR4VZxOLJfF2ubvZ99eSx9QxJBDULmaOKtvTdV OcpRWZvQUMaaemMRW6Rpf+/gyL6l+/tTqf0bG5esrkE12B9rXb4/NrtrIvJSqfd7A7vYVztIG22b M6UgH23PlP4YvaGjP0VvmD2/67iNkMgNc7oGJDhFl0zp7s/Gsa7jEUJSSqzEYlkkOyXCAuxOsxDQ KecHjqcI2accVSkRSngZ/LJKHD8JcZQsG5R4nE2cJyFOxeNSSlw3/lDDfKuRBWiHGyPLWfbs6V69 f0k3q1zEg6zEf9pHY7WkT4rVwpWrMfUZYium9BljU1h8HYuv4/EaFq+NTemjHgrjDKJN2r8khnYK Ra4LLvJulA4bK/1STmRwZGROV/R04Ex3FFViITC/q0+fRD+gzpmK85oZliC6uW/fsl72HKQTVZ3V zNZl3agL4oY4pbVPjzvo03fAGU3KNaw44qJlyBtkoHL9PgT69nX3dSfZl3atYU8Uidj6SEusBtnO 76mOsy8q6t7viJWygo1T+ww51zPS49kInNRKTABBfBkaXJYirQlPviyGQ8uWRJADKrJsNoo6b0sN LN8QswJNoiq+QoEhkD5IWLLkHKPZ0KcvxA3xn2ljIW6I/9puGIUlXgldnz4B323rM+KJ4mNMmb4A 1sGhVvYs+H89Hp6d+hK7TccgmRXbgaaRPbTyVVoc7jPntPai8efXGxETqxIX4166HBbF7nGKx2pZ yk2wu5wzZ3DkidhO1gKIv4L8GOscWMEkgeMo2KR7/8URfQuSBfm6i2PNSvT+/Trzl1/A7aUzjzK7 S6QRfQ0hKvYay0/Bj5KYqoH0qv5CnpE/BL5NnlGbyALVOfKMpCLPqHIR10Oe0byN+HHANLJMlYX4 LuXcZvmPxKrOIk9rQ2SS/CZZqConB+SlZD54iXyW9EibSI7qIDAROENy5FNkPDsHPrhr5W8qfECz nBxgcaoq5boD0o9wjyjpkJ4lUdW2NMrJXfKDJEs9SMbL20me/DDJkvNIN+5D5CPkWvgdx0nZ5AQ8 k/fKXkLhVW6EF/laYJd8jjyE9LYAzwKbgVVAMbACx5pgeP7ODiEmzCn3IxxFNuiJmjgQpni/x09C JEJySR5JEDcZR3JINsqnl+QTMynAueWklkwkk0gdxqASCRMX3guqxOw0TrJIMYkRO8kgU4iPBPA+ lIkESSGpJjXEQ8pIFb6rAuPWIjKBlBAD5s6ZeG9KR8bjKQjmB4/SIvqM5Jfuloblx1SNqtvUVnWP xqB5TBvU3qObrHfqdxnUhnuMjcZ3TWvN1PwNS47ltHWJzWI7a7/C/qnjDsebzqOuZteb7nXuP3gO ehPeMu9Tvmrfx/4fZnRlfDeQiWW4Y4EPM4szZ2Xuynww84/BiuAdocbQufADkduinVmGrG7YgQxv kV/HbFxGuqpJO5lOFnyHmOE285AaeuSIu6FBV6B9AS4xiUTgVNMRSutTVpVkPpaRURc7Nl5zi2xv HaQFh+u0t8BdXDf07tCrRUPvnnFUF52hRe+8/+77tk9etVcXlb3/xvslxdQetStwWSSt1qWJZRVK 4xPxirKy0lppfHk8lmWRlLjyispauaw0JMk4k8fUSixM5dfPzZdnDGmky2N1c8vUoQyry6xRS5k+ R8HEHNvsBTkTC4NaWauR1TptbuWUrLZ1jVm/0tqDbk/QodM5gh530K4d+rXa8vnf1Zaz9ap1Z++S NRMW1mXLXzfoJJVGMxjy+cdNiLbOtTptKqPTZvfotA67Kbdh4dB17kx2j0y3m99rqB1miY18rrpc 7UJ5iJMHj5PskQ8Pm2x0WmwwLeKDIx8fNiLGKATWbT9OZbCoHBv7NCufJuUzlUtz2OF8I23PjsVz /mkymnxZwZjBTD0qEzHZTNJzsRdjP43JMVPM5AjOcnSqO0ldXZ2jurqoqKfH7q22Q9rLbGdK7WWw eLKH+7qwIpjj8WgUkyfkqGyRY1nxeEUl5Xb2amMy6qSO2nLC4RynXrVh6I9rZYMzlhnMsVIdHVCZ /YlQZFyGRbWb/pZ+b5InYFHJWpOeThh+RW/Wq9SWgEc1YLToZFlnNd4ytJvVvd6Rj1UmdQgla+mh TDIhCZscstF28MeHrAr/5ZBZ4b8eMin84SEkPPmCVIb65qNFqENxmj/gnK06Qceh6hTTwn79XBSz N84w0KL3ldTZ3jpVUpzjsvACVa4UFY07XXRYoXK7Qig+vAipTJJa50ot3t16+Y9vbZ99z8+uqFo7 vymgU8sqnVFnKZ2xacbcW5ZXjl9224L2LR3lVq1BIx+z+RwWV14iMOdbnzz46LnnFroj4wIWZ4bD lenUJ4oSjde9tGf3d6+YHC+Ka+whlAq8D6m6FfXKgTZjeypYF6VOH1LutCHZThfS7HQgwU4fUus8 IZWiRcjgtslI20ZhnAf+N7MNWLFNxgms6ehhG9OApSMwSOP96jmk7kzdqC3e4CYpKe6hzADRrPh4 e3lFWRSVR1teKMVidmYI1a1zH/v48eG/evPyvDTnyQ8f7DhSvuHp657r3/P05mrpvifPPjYrnFBd lQjP++aHB9YcuWbqOXvtvpdYniJl8h6kLJ9c1p+RSOcoWMlRhfHUYOWpleNIY2JQsqf0emfEGcHD ZwxSXcq8L05PxulrcRqPa/yDSI+5IwHq1/D0oAXp2bQZySpSiraNJ6tUyecLk6VkdNTOUjhGyntU BrNu6E6WQmmlzqxTq/ExrKEDOhRXlR56ukR1ZoOq2RFw6HhqdY6AyxGw64bX6m2ZTkeGTTtcorMH lHSPfC7PQboTZGG/1plON1hJt8IsV9PpVo6zvEW6j5iDJBTUImmHnE6/ZpDmHsrq8LNKm24li07Z q0dTxzNtbGJECyhyUZ6DhGmHYT0tHl7RKZ0rkuHLcumQ1CYl9pQzE6lo0doCbmfArh/6g9asVavx oXo2EUYzyFK0YOSvqh3qCPq2b6SCmZlWHyuhPlZCfTakxWdAsfPZkAofyz0zeTFBI4lUYklCTljT 6Qcr6QcrNRms1GTlOK60Dkqlh4vKablvkBoOZ2VVF9WeoAb0OwaaN1A92zVI8/uLUJ+V2oyGi3Ua PdwWb/T0nOIK0WjIvlCbKyrtrHCz2q5kvd1lUY3pKlSqHSqdSWuqWnT1/EuevqyucddTKybuHj/8 ht2u0qPdut/ocRgcNQuXLi+55y/fnNvz1Jnbpl61ojHDoFrkDDp18cL49P0vbNhz8pqGYJDuzMqG GXU6W6Zj2JkRD2b5TD3PfHzXfZ/39WbE8jKyWL1APzAT/UARGTxcV0JjprSJwIqJFIZZwUrVUI7D RCZm3ExvtpFZ38isb2TWNzLrG1n7YByUbCkvSblpO0k52YfNjnWsFI4TL9uQggOMj+KYd9ysbNg0 ZT1poq+ZqOnCHgIV6kwdLUom32CtZrrIna9YPWhBeWeLbnpU8tZUciNOSNVMnSvqy4i4dEOHoPys 5OlcWT5/1KWT2pWyCJUB66PImXRS7dD3hFb9SqihzyWN0On6RbtgPzeZeazOO8P7nFcmaROCFRMq DNuAFRMqx2Eh8jzaRMPIyWOwhME2S+kQkUyeQDSE59MlUkC7xHPr3VEve+7Rpz3/hKLWf4qnKiNL U/YSVhmKWZ4UMRVFR670Z6xDZ/2Zwng+sPJ8ynGcaGBZbHInZkUNtsAs2/keG5mRzoWSYuQIf854 PEG/xPzpjtrt0mgp9XjkT7WurEAs36MdzhZpEXlAf6SxeaMZGRGn1uwYnk1ftWszWQOosRmk64d2 jjYF5/PiJalOb9Kq1MgQc4Z3aGTovgxnuq1vQ+ozSMtx4uaJxc4sJbEKI7FgJbFgpYNyI7GHid46 yz1Ik+nGnBadFpmhpJF3Srw7RsFi47w2tMj6oVPevNFEvMaGFW2ugFOPtvlZUVTOPqq3Z6ZzRpNE ezyRPJOyLandWCuZi4u9RUWGQp9P6SxRnZROFBmjMJ4VrDyrchwZk8EyJpRdYjIZWO0zsNpnYLXP wGqfgeW0gZUtgi1ifgRIdkWH0ec1F/lKCjXh3I5wpxh+1Tkw8CpDfr4h6hWGYOm8tZfZqycVlZWx 8diYshijbAxWKCVobEx2s7FwSPLSMpbfTLo1SZ0r7PdGnTppuEw2uoMud8hllIabKWqa34dMzg+s jhRn+/R0u5peZ8wIx/3rrQGn6XyRXnX2Lq1BK6swlMGA94CwperxcdmmjNzAuXny46FxfqPeGXSn W7LL1XbMeq49lLBaXelSrjAMpDBsBP6YjUyUMIzjUowZMhQWljJjlvpwbqkPJ5bacFYpM2YpO8VG QlWzDIXWhMrP+kHW3WP46q1mxhu1mLBdEWymFBluKdSNmMfj/hJ7hWRvWZwNddKlSnW52Z1hrsxI xGLu4dWRyZmSJOmcYZ8v7NDlZ8wKJsJBO60JVpSW+CiGAc6w3xNx6JpdGOEbg6UJ6b3qvRNa7pl6 7h+jteXp3CyDNy889MPyZUt6imYcnCG9gPEvRhImLcGIb9nIGdWH6ijmeQmyJ5XhYjZwsQLlYsM9 FxvuuZgNYKaylD6C2eM+zLpCaeOClVoFVjpSsNKRKsdxVegEhsQG4ke3aZ0dYzVLrXSb54d96W7z fE+p9IwoQMqob8wYWPXh1DvfveuON29qmHrXu3fd+sYtjUcSC76+cePXF+fF59+7edN9i3Klex48 17943uP/fuTA588tnvvYP5669Ls3TZ9z84lVm0/e1D7n1u+wES7GQy+j/mVi7ryjP1uTTghYSYjC SDhYqXLKcSREw4qA1x5k5gky8wRtJjOdFozgWBCjhQFiz8FY4ZBGY0IyjYfcHaYxQyVeQEThSKf1 wuqD1kQ1ZqArv5za/u0dd+qdUT9r5sdlUPe49jXrp+UdmTCvJ//h+6evasqW7+x94NKJw4Wj9QJZ rfXWLdw5b8bacsvQZ7nNy1gOsx7eiBRXkAZyeypkK7RX6vDUlSwVlUoqKlmqKlkuVyKXj+WlEMyr szOTQCmMcxWGacCKacBKy2mHaQYyC20YHR/dmKKplHcSLHAk2uFN9xhsvNhzpnq00xBtDQbI6VrC mhO5UMYg/3z/zcb+Hm9IZmNjLaqJ0+Oh5fFEPC6mAkaNKzuUEXUZVdvdBbVzJmwRxsLUwFkyOaNt y/REbMrC6kh5Qa5rq0U3PNQw019XdvuTDcumhNHI6FAHUMVLyufVxYZ+OWpEDDTVsrlq7ob6yatm 1LgsyYnTS4Z/lx2Ur522xqvVDE+LTpiJ1qZ55Iy8DPWmlXxwnEzGpNmKKfFkZjKYSGGYTmHUILBi qsmDUn4qWZpyuui00pQdc+XS7FJTwMeuDbAGPGDDVQHW8ARYdgSex048tOKHAsro4eQhf5pdnI9a 2ZDKVHiCJuDeMdB4ymiPVNLKlNFEpyF/TqYMTFXaK+2eiRjJH5kcUOfN9gzSvHQ9RBacsbMpeDLZ YztjQ7UcM8ZSJjBiwDVaQVWignLnR6EmHb544qqRl9Vvf7Rn8oZ5E7xGDGl1lrKZm6ZW9dRnl85a c+nqWWUT1tw+JzmvfaJTo5JkjVFrLGroqamYWZ5ROnvtpWtnl9FLFnxtWaknkuXLCcMLos3KjYUq Z5ZVTp9QUlY7Z9OMjivmFlj9YafR7nM6MJ/NjAWDxVNyKqZPLC2bNHsT8siKuv42Sn4WWXHMl4J5 fXaMvU4ehiJKxYaxlQqP0q0wDoAvrPisI7WPnDyCY3aNg02Dgum6XYrB2ifKRP77SdupZNpCY8ag UeYnYi27MlR4W5m83SVGPcN3icmdfI0ytVPmPmcfGi2IS3X2TKeTu2zYyOFptNQ7MapJkgOp4JIC GmG1NsJqcYQVnQjr+yOs1OB3eGwp+9iRN0oa8aRbOrDS0imM68BKgpXjuNrzPHZeYlTKxucYCZ5M 6TFAN8Rn2WZh2i7KjTIc570eKzBcibk7S/Voh2ZPuzDOx6h2Nu4b3HZJ3+UNfPrn1OXP3tbatq0D AwYMyqNOPX33suP7ptTuPLpdjglznPv7/Ouw2tF11TzZK+KYVSaNfK55D1aZSFYdik+kpYMjn6bq WaHPQfbomMgtonBYsZgcmuVjIi+L+iJMFJTQgmJakE0LYrRy1rhZsWKjPNY5hd69DqnCH3NIpf/l jI5/FG8UGwnBI1UxZvxzfiRUCt+VVn21ypaZFwonMy2q4U+kz2VLRl4kmp9plYef1lB7PBLOdmol GqPUJetdOaHMqEsv0zyJBmWNMxYMxWxUHbfYWZ9tt8g/O1cktOqgF44tWWcxnj2lqjFa0aLBiXX2 B6oJBmi1JcPL2v+FaKnq5B9hLpAifamIdUp4StEU2aj3lptQYspZ2Slnxabcxpqh8kH6nxTcBQkr frmKsNJFaliJwangD1nrpjAuYKw0ezWDki7lsnu/T8pt5dKEk+WUYO5cXjh53CANpKyvZdGsLFXw o8Kpk35jaleRIub3UfoENnXu2bSoRwwHTiUX9VQX8X6yFJ3DIow7me8PI6Tx3AeoVKey8cwjNOp0 rVUpA04t95h5ykorKuU6W2YgI2yZcHtH85aOgtqtT67Z4ymZXj2pt7XEpMPwRxuYMndlee8Nc+Lf uqVh+ZRw98zJGyb5TCb036b5dU05TSsnT9s4NaepfOb4QDAW1Nn8Vn8wIxZ05ndePueUt6Aur2n2 lAZY9wCs+6Z6E3zwGHceqaujhmhFukaBld4ArLT+LKzYq2KQfpoKuJNscJWMwKJJZv8kq89JZvHk oGRI6YnbUDE+qlIXD1L10fjUQJNtWjVkv7qdOR6YG8aLPjU99jxvM+4/Yz2q8CSer3p27jUVQyut 3QNr1Urym2XLbutJtjY1JeBJcmMwqdE6Iz4/Rpa5bS0tuUtvmpf7rLt8bipSm2pMNOypr+2q9NMP tp24psker8m7FPVRpcKMWV2l9Kr4GPpDXlXMNv3qvm2NVy2f5Bg3pXT4wOx5E5ftRo2dD4tF5Ffg Fr2xP5O1x2yQAX6PlS02Nz4MYxDFBYcDimsONgErI8vzrrmRj9gFcNEZU+YiC7X4PwinDOaWMDwJ 0mHnVPnPJayt15tbSvIHqaZfD7MNvZFkLpvkeXfNKbRe3Dl3kRNWCcay0KuFRl2wckRSa/0T27qK eu9ZMX7ypgPdyY6G8T69RnKYrYmJnTXbr4imeiZWz61LmtjE5Rt2v93szwk6UrsPbbv2xV0TbBlZ PovT50iEo7nRY8/Ou7ormZ2M6Zzwa0lkCezyAPYsxuF3vikVrptAjYFqVjurWctezUYG1ax0VLPC Un0CO9gJKeJWK2IlDMfBStuuMC5S4nF2EStQBme0yVidCKgsqJbqAd9UVHXVIUs7ltBQmJTiNDqx FzMa1MHzU7+xVRBDs9EmXsaYbMxAvVJ+QGvPdLFFh+YDC5bdPC+3dOnti2dcndK6wqxM6R+v39tQ hxKEEjU5OinVlPCLArS9fW771f1Lt564prmxXjKKOcxQI8rO0j2phqtWoCzVY0gkkR5Y6wBatSTW up5NjSuqqKvYUCE7WW1yRmAlpzOaz8ZR+cxa+cyM+Ur7hrLw2ZGG5LeSEnPnH2G1rVyVLnxgpYwp YVwG5g2citkvGs1/eZ/qNpV0UkVfU1GVKrPoN/Gpvo+WWDZaJIv+o0ylgPWk2zbFB6z0i6XvJPkk B41dEqMEVFBNLDqmWKGeji18kjtRoRhUKx9I+IcGQk0bO1LLW4tMWqNGlmStsWLuptSGJzbXTNz0 yLK1dy8peFzeuX3SwtosTBUT0bYdcwvdGW6txe8wO60mo9/nrN01uGvr8SsbG7bc3+W86q7CaSsq Wc+Zg/2r16l3oOdcPuCxsQqoVLxAutVirLRWEMoAAaw0YxgGfDZQPA7rPa+lHMynl2M4U9GcET9T 3BKZZmth0+IzpcyxnzxVpgyPTiXLsM5xgSfUrbTYsMOYET+aedG6K5NhlXQdPDsarTuUF8gpj1he 0Rn1aof1FR2aJrgPdFfYbGxYeUWsZf3U2JRsk05WW51ei1pv1PvKOmqWau0ZzuzIuT9jdQT9olEn uyPZzgy7tmfR9XPzzFaTU/GPwwqqk+qdpJfMOtzcnDUbrcdnA4UmjJE/S4XnZDmyHKS6rFB3Zn7z 7JYZZ+qaYp6iM9UtedMyp5mUpCKtSCySTItOlZ1iQ+my90tt75di8ZClebQZ+bIUjxkqXpR4PvE5 f3GUD7JZtOok1gfc4dyMqZNeYT2Z3TZqkeF1F9smu+WS5vwpbgOMw66K4KqJ9K4cxCbr3XqzVlbb Ipmw68qNy75ori+arrPn2rl5Vr0KtnNGgjD0yo3zes/HsXoJe8pHYU8n6ST1/Y1YAb8UDoAwjNrZ gR2Dn6XcFcX5HS3tZyY2R/LPVFjVFS3xaX7WBNW9cRqrf7Al3G6w4TufvPH+q+eLDTfAmJXVsc7e i6wXQqs9xnalHrd8VO9JhIIJr8HgTQRDCY/eIUz1JUZrXtPgyc8OwOskwXL2jJzMxhpJm+FX/SQz zu4Qz8zM8ev1/pyzJecL1xetpVhGpdMbjDafPZKp1Wlh5oCP172/qZ5B3VtBuvtTU9lwwLQiFiPl K1aYmrrKCOx0yGMzTUcDnXIvbk+1lLXU1HgKzmQ2TyWmM54WjdJks4KHNoXVN26yN04hWAag/MFy 5yfTF9tHJYYGSrvtTpcuOO3GllJlaMDraXqFwk7XCquNVr7m9RglhUxaWdbosD7J6moZ2t97dA7m 5HPo/shmOQ7rBxUtnpxMtxYnYdYdyivyNC9PBeXCL1pNqZ5WMytiY2vzW8Jp9RYvqMOGnsV6g15t 8TmCWTaLXpOD+T7eFZPJ+OE75RvlH2IHxHTsoX8t5XYUNLN+s1mH7qA5YnPSac1ldZgnsDEtWOkx we8dZYfqtDMgU2arg06bEVBZi+UyrZb1D+he0QKeTJkhCsq0gYC2rEDFWs1UOboK0sW+oitiw2Vd 43JSRnCOtVgrV039lWn2h273kir5TxNbxkWm/LJq6oJfRmYoi5+O6rozyvLRW3wwlyw7nUyeSnrR irApuR0jPNvpJP4nxQdvU5gzUfGUxBMalHWPN+0nEetIlRgwYy8C+2RNqccLVwqcJ6MD5FrJCVdK wgLnCh8A3ui0XhnLLO3ZN71yWcDhnVzx5/qNswrLL3l80/oDS/Nt0ZJISVFpTji7fOGV0/Kaw9Rm tw8Pr+gpbi7yrlhQ0lLknb2440+RPJ/+msvaVtQG5K2xcPa8ouk7ZucHPY7CUKxQMkjRSd0Tajd2 luSkusujtVVlfv+0/ElL4jk9U9p3zSnQ66LDnyxcFalqze1eGa5sGVpUUyfp/AV5ue7J9cHiWlZr DqBteQRj7VKy83BdOR13frky3VWNWcdURt5OVrO8Ib4oxcYAfGVKGQgY2TEDX4+CFxnuK82xgqnZ Tf5pyoAIlcqB4XV6OYYPry8YDdmVOYhGe76WCR+unU8G3fIjqATKKNpX2Fpcu6eB1wmnVgyum29r nb97WtQvGhHJ2r6oIburc+gmETN2RN3WOmnljb2sjb125HPaoS7CmlOU3HysLjYjtiEme1j3jCSC z8/nMXVHWCm8YDHvV7pxzwnshcrE8ohiqS8uh6RNiuWQT48awimUbvxgRe1hv61Vsc9bZ5Jph156 rMhGNl9csXKyhpgVRpRCWnuxAZz5E2qSDKMmkK/BPALdtUlLi2vG5VUDIuf3IOfLyd0pU10FzSuh JSkHbccQ/zVlkAKhzB/AH7F6rYRRL0tO4B3VLGJKp+arVzNRGDI8Bdg7hYTyQuHJMqpzWzOb7KJA wB+GTj6ZRPuqjGtK31OcP8xBIBL+f7UEtkfnzMoIxHxWzfA1F1uEztE5/FiSzELvbB1+nl5qNiqu Sllr1tO/D5u/WDDOvU4vM5j1MgaGepPPNvz8cI7dnbYZrYXN3CSlrExuUFYmldxGs6WUETbbYjtX wHysh57n08MGW5OSxen8/dJ8/WJejmbh+TKbfgr1axinzyQfpQIOtv6o7B6JKx6ZhOKO2TiLNo2p ucoTIaw4nxVGloCV6Z5So0MhDwp6KFTK17tYxeaLXkrFNqD3PDaTeVdn1mK2qCR0zKxRuS3CSmVQ GJcnTuBl4FJio5qBtqkYAmpS5slTa5sKqloLMDhJNwjIfzZPEn7s6rQfGyO9tAOMtQ/KTxiI4oCZ N3NUXNBIfCFCGeyi6027kPgU3a1+jTceTp0rv6Gweksj63mxmqb15NcXVm8dbUs0jkyvJ2jTTru1 taq7odhW0NHWnD3vstbwaH5IseqLWpUvxsAFaUQR0ht12ztnZBRNzi1pGOdEczNNtLrIwVJyV8rK c5BlY7oBvjiX0u0uNztyLZ2bqF6BkNGGvpNvE2C95di9AvTTY+mmmDXEKUPB1HH+7FZhetZPjrbF yfQ6Stra/5OtLzTtVzfIo0a8t/3/0CBfYCgYaAlrj5lH411YiK2hPZnKrMujuQ6aZ6dxM42baFxH 41o6TvHoKetiMAJYKX9gpdkCX7huxiacoSIDNYxZkGNz2zELcs/jTXisDRyzkvaNyCbsRaID1qlY fZLSLiKYrCddMsXuFNZWpf/EfEwMrIVTSDg85Hdrtnx784bHLq2o3vLMFnDls4HatTNa1zREA3Vr Z7SsbYjQP1x6/Lq2KZcf3gyeCt7TetXS6vLFV7VPvaq3unzRVbDNgeG75DdhG+Yf28f8Y9GKL9lv wFuf8xsPWLft5q4xxUmmrJBwL9mX+sZabTO+0jf2Za6xL3ba7q92jd2xKLdhcipbNNUoLC53wKHN m9beUbB0P3ONlSmusaZEw6762u7KDPqny75zdbMtqzw2XCs8Yqo/oXJhk6FRv3NcbZ572jXPbWu8 cvlEZ159yfB9eANh+Z50ayk9AWuVkWWHN46ncWu6/QIrFQnMTcUE6+2tbBTjSG+wYW5+VkhIBtrA nJQ+OTVudUda3Wy2oDReSvfFiwSrPaIIsHHhl4xjuEk00hOSRq/TeYPZbn/x+JrYGDsoLU/O5Jrq oDmaHTSpZCov9YTser1e5yqcVjnUJ7qr89Xm6oqGhFXWGQx6izL/7hg5I72KFLeSV1Omora6thlt V7Q916Yes5SmtOBKGI0G+OQhDGuUMGqSwmiOJg/S36TCfD2NdQgB5jRLL6fhcIA1OIHn8VMPbFOE AQFiSiEeA4KTqTjuV2d6ziSZCt+pNPzZPtO+xL7RLvNls1+zNbOpng+52xVm5Atm6eUybFMds5xZ lN4Xw708FrYr6f96uUx6tWzRVdOL5zUWewwqthyWrJtbNa6hNJBIzezsSCXyZu2eld1Sk+fGVEvG jgh9VkVr0bhUnjs3NatzdipBLY3rkN9evys77MQOwEAk4IhV5MTLc8NZydq5E8f3tuabHG6byeqx 2f02rcfvccaKMxPjcyNZ4ybOYaUvOvI3ab3q29gJvvBwHrHHCtKtlMKwKVjJC7DiblQYRixghdDk NRecibUEzWe8LSWYuPZrFT/1mdOs6S7jK0Slp09xZyvf8Wa/eF76FRNQab3OFskr9DZhyni51cE2 RO4VY+gPmA8E88vKZm92pkun1qtVC8ZOCLnP56tnj2RkhKVb/pu6CL9kkoRPVUtKJbzDzu0h/wb2 mEwmDRRNRsf06eFkKJREnfssZZLHJye32JJnJoxvwX5A1aGcdj13pJ6GE4MWlb7zPp+IMzcQPBDn Wxx4fb5kav0lppCfDHnQ63v9cHYNF41J4FdbQz4WyDh372itc4+dJUfto7Pki42CtN7FvM/yd9DL 3wHfczk1JlgtSrBalGDbBRLK2CrBen5sd/3sKGEDLBJON0NgpWSAP1XG40ywkSU7QUR8zCNgPL2z oDVhVPtbMdRSn3dBszZKjK5Gq9UFky7hgh71PfPlReypFJMvOJ8dQbc3aNe036N05loXdxd6i1qK a3c3wgnN/BL60eHR9s7pE1fduFTKEiOgoX/OWFyf09UpbRMxrCxkYe65G/bJJ787js3z6J/YAmJY WWHMCdMQFyGqTLOQcGWfGVhsMxJDIUe6JbfDMKlKnFCJcYKdJmw0V02zchExKYtmZ9Eok9h/nR2l ESU2QrMjNGGll0VplLle9XZ3SzSClguhD1N6NIVR+F2UEJsAIfbjlAn3iOa2Ro0ZrUbeCcC+yqSF JHuUsUCyB6uaPUnKBgXKAWWVM8l6Bu3oRq/0KjZb1nR6K528p5R3U0mWhk+rzBm5oVCuH2ubr6rU bEuSNxjDTvxhlXxWwppDwBuya+WHVXqDSXvuKbbTXqWzGOR5JodexjRPwod+KMNkkv6oh5dS0hmZ tcePfK6+BtZuJO8ex1aLk6lJSBpWl7AvpYpWMs4ppPEojUdoPEzjIRoP0kQmzVXRPJnWTKATauiE Ajoxn9oiWMbGD70pU2DGWCJCRAR3sKEPVaIZp7Cbp93Koq2TW5XzmDHrbDNsG2xX2FS2lMPTYitr zWmtuS2f5rNj+aznsDk9Lavyt+dLjYj1TlNagDeZJXtO1dWdhi25vRWblxQTZmXF1Eyw5WQYGvsi 0wvKckI7ZkVZjMvGmHyMVF+jUg//RzZ7c0PhcX6T/F1Jek42Z2CVOYHQ8GdqFWs5MrMcOvmXkvSy pHeg2GMPmfS2RN+SsFMmw4cXSuSHtS7r+UyRbtHrh7aczyKrS6s3Iocw9xzK0OuRQ/AY4+0J3ZBP hCQdBqGU5KF2tCG/ish1x0kJDGNHycPyO20vZC3GhELqQ3k8Clnuo9j1q7QNrKooUR6qZ6V1HA4T ds1EQqtitMJIjRE2YWC5YjSWFOe1xoz2YKuYj7PWwu6gfFEFpqXM7Ow/PvDSiLJwzPYVnX9n5Pw6 vVMpxGxxnsr1OmciHIq5japfvK0yurPw6oid6qlv+D866kxEgjGXQXX6NZXBHg4EcxySfvizfIvT pMZ8W0tXDN8PktUmp4Ueo09YnGaVrDFoh/vpDJCsMrqsw4tY64FR8B7YJ5vMOk4CSOt4JLMyQPMC 1McWqOI+GrdUWKSEnmawYUlNBvVXgSf4abjVb3C2GtpUM0gb85JjJMf2JCCVrCSxyhuV+dp4pZPt wY2Xj+5FcCrOP49LK5Xt0JSUZkTskmaP3iYPv6izZYdCWS69mlL5U409K5KZbdcMH7HZ1SaXhVar HAZ5odtnUeOlGPNQofSW06hmnlakpBsTnrfxqypJMuE4sSElHrYPLq7sIyvC8XJ9g17S59gxDTnk b7Gir8B0BA/OPPvYkdFzGu1Oessw207LSnklvWBDPPNsainbMiO9rdFZdENvuQOsyaC3DF9hc7L9 tpLKaMeSM+KGt9HHsXlG04Rt7trMaJbF4/HbpLXRHLwNodVYPPaIxefNsA3dgzcK2EyNyMcUz5kR b7258HKjtOmwRi+zlZx3T6Pn4d7VUX8V7RD+qeHnVKfT7qhh/NgcPHD/luepF8Ef1ULiKUt2dljv OqRWF+sbapibjPbjFxjhK3iHvUOmeHjZnZEs8fKYHEfWpDdQfWEngxiWixZAnlc6//J2bSzhDjl0 Gqp3ZDo8kxdWZ0RSvVNq5qXyDFqscGlc1R295Zfct7x4+JTelxeK5LIVitxICE5Z+bddNyypUH9i tbLKS9E7OrV5DQtLqxc3xv0hn8Ye9Pj8znCGY9Lqm89NiCYDRmMgiVdn/UajvwB5Om74XbqFvIe3 BQ0DRm8msb1xmm/c02p501XpFM9Kt2gsXvuNarPT77R7DVR1rdGXneHP9hpvDZcXFvhf1RowC2JP 4dwXiNg0GluE5cuJkf/QW+S7lRl0oJ9gs+nuY4ZQDPN/K/LmdB0yB0tC3IjCyc2WJkZHVenun96C NIcjuWiffLmRMLfBBWE5Esln6cuPZBUwLhjKjfIIJBjdUAZeRqXkXjzPpUixkXj72Vaxk0fRBqGk oBPFoyRfYskf49i8tKh2YiHD+uaiwkaA3YMOfyAb1C/A/6brt6lJEQaC3rS50pvitU+qzK6g2x91 qDRSj8rsDLmxPq5Sf2LG9h2t2WnW7DZb9bCWy4z7NdLDUqE0CW9xWg4TrfEMNtKcwboPL7NKDeKv S0mFDvvwIgf+6DdQN9T0s0QoHI+HNPYM3OXa4SfoP9Q34R3QrJRbZo2zzKZGslKBZXfYeC2pK4K1 0Ybizhq8muTwjr6AVygr9ZUPAOjfFvcsXqCmlqDfkeE0yRWzqjLD1bPKKN5B8ngzbZJ66SvD3W+9 PTz/xya7UY3XJtQrf/aLdzZt+s0vX1+FNxbRUOJtekp24Yk+wBNFSdlx4sC0Fs+EUZLiH2F8hDUw DrgoT7LOAnNb/oTJUv6IrFoxs7K3Aisc48ulBKtbbKzicdAPMqs6KmQT3njLCJqpeuGiRYtUki3T 68ZrRtKqbZJ/0zu/+NlKrDJLajQpP6JPvP0WfeIVvQ3vzmk0qtPDM/B8D0kPoK7fgL7Nl7KEcsOJ Iq/WatMYjDEjMhVLNLATOhKNJpFwelihqHRqNWyjamUl3hGtrKjwemW8K1rq0cqVFR4YU6uVWy2S 1xs0vZkpRwoLI3LmG6aQ10stn3xioVjLMb0h4t80Bb1eyfKJ/IQmlsh16O8f/txqQ35p7tc7chMx zSVr0SwkHPr7qNqGv+Gz9yE+HtOuRZ1qwYj+ZWVndxK+V/9FLqkc4ZLCJO5kKscqtWNL4RhnE/Ow utjo38W2OLt8TJ2QUDlIhE/+IuksAiueWbAyBQB/yGoLRqvYiFiQ0hvYpvEUkZnbJ6VHWSsyzDBI RBnDIoS3F/DzluwhDEwYCH4PBlsMDNgwznZUiw3jrKdX9qmyDt72PuvjsSjGp5Vsuo2OkP9d3HrC r4XZ5ui7lCr55aL1fVfuemJlsnhd377d4D5LIDmxvbhz7SRPaPKKlqrOSWg/pP13/7u/d95T/3nk rv8o/EzvfZd1Vvpn3vyddbf/eF9Ndv2izdeidDyLPuVhtRdvUP8hlZ0dotlBmp1JYwGanUGz/ZR1 7F6ap7gDHWw0U8xSambmLqaEmZbkpWfTYKXMKwzrgxWDgpXhUh7bgm4JYeciNrIa2acRk4j32Bs8 4DcO4Z7gk+kt2yL+JJsMKJMNPa54BO8xO7GJte5QbFYeJrRa/qZLad0QmjVu0+RprEDyjRvJ7yuW JXx6wM2ruFvPb2xFL6vhy4yVObxZcONFTSzTP6zB235DC7Umo0aDlxap5XO2mot9vno6TmVy+ByY hGk+0ln06gbmrdDaMvDeol0v/+Jug8oc8tp9NpPmRVmFfTbY9nL2Vj0aL1h7M6z9AMp0LXzR5rwK mgzRvCAb/6eYWb3MrCnqYRvpsHyOZsPDzORBMTxaloN/pDpt6+rn8bOwRhgLxsELzu+ljLCi0V5V HYlUo/AVHi3zaApn2+BTzBUW4p4f9lYnm0K9nzzNiqNSAFnpI8q4/gLjsInSRRsVNenldAwElC3B D6j1Vv3QeIvbqpUNVtPZeWuqHZnjZ5Yr2xQxsFThlV/fhO5LJiy6pafQ03zdhtNSGXZ4qqey/c5a W8jjQrNhpoaFd+xYmky212Rl5WbpHCE3XDwWd3bMN37hrsba3bc+t/ktvUPxtq1Cm3AH7NdF1cfh tj6ZymQmm09LdDBZCesIShS7lTC7lQxK41OG6bPj06f7MM+EiT9MxXFKnE1/UoiNp2RLgF3JvWvK lQF2JRbKlSIbgOWPKEN6VHBspUL9tqSLLFgp7eCTKSeywTIhhdtOYBOxaUUTqFKUEcE4ZWCRE+wT 7B5snTSmDK2z8/8Riahb2VZ24+hWdmzMsY3uZsfUis26sDuZtxFop5U1dSyqV/Nmg2VburHQKAuU IWWjn5Jlo2OMLxmjnc9Ed0iW76jd+vQlkzd11Vh1Gtli1o+fvaFhyvKGrOTsne27kVdajdGi3zRl TWsio7xjfE3vtFIM17QyekNnTeeG1PwbFhREaudPqN8ws4Bu7r51ZaU7GLZYMCrIzozkRLJqO0sr u1JZqB5up9+qzUp1V+a2VoRjuTG1NeCxeu0WJ/K5cM625klrOqqNknb8zEvQ9hdjPvZz7Ioeh3bp bKqGTZYLaCKfZidodpzmZNJ4gMaUBirHR3O8NO6hcTeNu2jcBqczzVbTbBVNBqjSWjlYGcE2aY8P wsMaMWVNGZnD+BjyzpNZiPc/Rs6lgjjDxqof66TwwebarBOxsYGGjb0DniAq3lZhc91rrPqxzXYp Aw6rVMVFiUChksGqZNRmM0RnGdhLNPCjOarLsM8qPdtLpr2JSfxUANsawTZwihooeoHRzuCCLWai 3RI/H8DaKg82Xkfln7scd4j30oY+MtnMGK8YtPR1tTOUH4qWhGx32N3Dj0rDC+gTdGM0Pvyx8LFR m8YW8jlDfq9ZdsDZjx9wMOvP/SAm/WmohrVYK1Dj7sE7CLXkpZQ5UUkTFcqCkKy0WEeZZVO0Mt0q gfGbCyjqleylg1wU/FyYMpfVi1zLjNINpVeUyqVf/grS83jPiqBjxg1ZX8r2NWJRAOoY29TtdPpQ cfJTpvyaf0bYbmx1fgdebR5TdXrw8gdbyKS2t9I15lTPG7zycOOy9u18beEjrPOVQxkLize92ear aHoThHxP077+dRPXzamw4ucusPyhNYxrXtNSv7GjMNGxZ+6krnimLxyUJumsBrXLMRyMtRZveHxD NX1k9Tc21Nj9PovJnuGw4x1m7L6ONKyaWru4LmzKyJGs0QjmQc7s3OG71dL43v2wdBNZJx9VeTBO cw2Myw6xV/NN+NHOorLTQ6fZT0pgoIjHYp/KCwqiLJSdf0GYv9J5VGPAy0KDePvC7QribfRBvdmg QW+mo606O95ixNARyowRbcqJN/DxHoeRvaRv1NF12D3tZG/lQ2HgrWYv69+FOAya8EfxqwpUURqC X7uZMb2+c2p9sr533Zqlm9f8fy3rSqkKZW5kc3RyZWFtCmVuZG9iagozOCAwIG9iagoxNzg2NApl bmRvYmoKMjEgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9u dCAvU0tEWUJVK0hlbHZldGljYSAvRm9udERlc2NyaXB0b3IKMzkgMCBSIC9Ub1VuaWNvZGUgNDAg MCBSIC9GaXJzdENoYXIgMzMgL0xhc3RDaGFyIDMzIC9XaWR0aHMgWyAxMzkgXSA+PgplbmRvYmoK NDAgMCBvYmoKPDwgL0xlbmd0aCA0MSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFt CngBXZDBbsMgEETvfMUek0OE7TNCqlJF8qFtVCcfgGGxkGpAa3zw3xeIk0o97IGZeTAsP/fvvXcJ +JWCHjCBdd4QLmEljTDi5DxrOzBOp/1UNT2ryHiGh21JOPfeBhCCAfDvjCyJNji8mTDisWhfZJCc n+BwPw9VGdYYf3BGn6BhUoJBm6/7UPFTzQi8oqfeZN+l7ZSpv8Rtiwi5USbaRyUdDC5RaSTlJ2Si aaS4XCRDb/5ZOzDaPdm1UtRpOlvzT6eg5YuvSnolym3qHmrRUsB5fK0qhlgerPMLftpwSgplbmRz dHJlYW0KZW5kb2JqCjQxIDAgb2JqCjIyMgplbmRvYmoKMzkgMCBvYmoKPDwgL1R5cGUgL0ZvbnRE ZXNjcmlwdG9yIC9Gb250TmFtZSAvU0tEWUJVK0hlbHZldGljYSAvRmxhZ3MgNCAvRm9udEJCb3gg Wy05NTEgLTQ4MSAxNDQ1IDExMjJdCi9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgNzcwIC9EZXNjZW50 IC0yMzAgL0NhcEhlaWdodCA3MTcgL1N0ZW1WIDk4IC9YSGVpZ2h0CjUyMyAvU3RlbUggODUgL0F2 Z1dpZHRoIC00NDEgL01heFdpZHRoIDE1MDAgL0ZvbnRGaWxlMiA0MiAwIFIgPj4KZW5kb2JqCjQy IDAgb2JqCjw8IC9MZW5ndGggNDMgMCBSIC9MZW5ndGgxIDUwNjQgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4Kc3RyZWFtCngBvVh7cBRFHv71PHY3JJxJANkkLDN7w5K3IVE5IBxZlt2QEMBAgNtFkN0k G5OYSApDDrDgthRUFuRUBBUslXt4AocMG4qbwMlFSkstX6ilp55Vyvm6upLyHnKlopn7ejZZCaVU /qCcrp7fs7u//rq3Z2a716yN0miKkUj1yyNdLWRdYx6GKGnqjHQl7ew/Q+Y29XSrSVsuIBI7Wrpu 7EzajvuJRrlu7Fg/2D77A/hbW6OR5mScvoGcyh1Jm10DOam1s3td0s4+CunoWN00GM9+G7atM7Ju cHx6D7Z6c6Qzmswfw9tN6lp9S/egXQM5pWtNdDCfBYHvVWLwCnQfpdFNZIeWibKSyP6PUS6SEOVx XOtuL3tp1RUzz1GWw7JXLfi1JV984ItHv4x+k59+r+MrONKG8rm0FQ4UEmUwxM+m35uKWO1wEwxq KDaoFrUK9VrU4uLZToqxx+ke1MdQRWpj22g96lbUh1CllLYfVh/blpAc3uNsPeWyed50SVkyNkdx jkpXXjeY7egjyjvOD0+wHKzeGZaTGE1ps0exx9ij1EwK+z152AaqoQK2p7ewQwkjtJ+6UGOoonVn bH9iYoVykpWQR2JoM5kmSuyY8ml5qfJxuSGwhHIq35Agnp4Iy3uF0u96RPmL60blJOrBZOhAITKO KftdHcrOiQbbk1DucxkMbe5NirUuND2mdBbuVprLrfj83YZwMKFMR3yZN12ZOs2tXOv6SCnLNxwM dqlrvlJU/rIyCQ2RpqJTjzdLmeDaqcxAaKIrkD8D9QQ7wPZSEdub8MxTjkPFdHtrC6ftNtitvTUF 5R6DbfBOrSnYXViT7ymcr3gKq/PzoS973r7Zfr19tr3CXmwvsE+2u+159rGObEem4yeODMcoh8Nh N9gfE1WK7QQ7SFWg5WCvw+aQDfYknNIJdshyHvqTQ3IIDnKMNcwPsHkZjTXYwaOZXINyzGZpNoMd 6k26DnkViWuSFcgUuI4b7iQwh0DzSGd3GzbacmVPlbMqe1bW9Gr/D93CVmToXvzDl5O59N11DUH9 gCukV3DFdIWG0p1Dyg/K7rUIRX3FxXWL1/f2dLW3BKJaIKwFoqhhfVtPq1OPNarqkfYuHlB1cXK4 samVy0hU79Kifr1d86tHeqx2F4VbeLhH8x+hlsCS4JEWb9Sf6PH2BLSIP9Tb6FuzcthYW1NjrfF9 z1g+3tkaPlaj1e6isVbycCMfayUfayUfq9HbaI3FJx9oa/Dd0o3dqQba6lS9oEGvXbQ8qKuRkN9g j8PpX0tyP2XKT1GBHKNcqYwUIvMd1He5HFhqfiI/R5kDnea/xUosah+vwkDVTOqnu2kvHSYbPQG9 gG6gB+kF1o7f9go6Sm+xiXQVzl6JDJpPLzHTfI1a6HfI76ZTtIuOUAbadNI4RHcwj7kBthd6I202 f0OTaBrdQU/RdPS6g86a+81eRBfTUjpAB9H+RaYJR6Qx5pPmR+SgRehzMyKvmfPNw5RNJeSjeng3 00nmEd81W8lJlUD3MD1K++hp+ozdxo6arWaPedo8g63qpAnUgLKRHWVnxMPSHebD5j/NATBRQEUY NUw76bfo/zBKP47WALuJdbOdbJfgFW4Tjkpb5PED34KHQpqLUkOr6S4w0EfP0H/oK/a54BQzxW7x WfNa87+UTnWYJZ9JlHpQ7kTZgTmdYDY2hc1h9Wwju5/tYm8IRcJSISj8UlgnfCIuFFeI68U3pFuk hLxdftCWPnDOPGE+Z75J48lF19Ma2oTZnaLT9AV9zUT0NYF5WCXzsRtQYmyv0Mf2sT6hnvWz08IB 9j77kH3OzguykCGME4qFbmGncFA4Jbwitom7xIfE98Vz0ixZkPfJH9s89r8NNA5sHXjFrDTPmF/i iHWQGyvjo4W0iiKYbRddQ7/CLA6hHMaqPUPP0gtW+ZBNoLP0JVggls1yWQVbgLKQXcdaWBt7hB1H OWlh+Z+AhRDShCxhvDBBaBAahU4hJrwpxMQ8sUicJy4XD6M8L74lnhfPS7I0RhonzZVqabvUKe1B eVx6QkpIr8rT5VnyQnmZHJO3ytvFJvk1+S3bJtsOW8L2ue1fOBbn21fbt2N1XsCefRp7+btLYpOA voJupibmZ420G6uxj0Uojt3VzO4CX11UYK4UN4lzhSnYDSfpVuzWPbSRtooraJ/5tniA/oqd0oEu Y/QHyUcu+QGszm00BbtosHgLiwoL8id7Jmk/das48ifk5eY4x185buyY7KzM0Rnpo9IcdpssiQKj koBWHVb1yWFdmqzV1JRyW4vAEbnAEcZPWdWrh+foKm8XQWhYpheZLRdlepOZ3lQmy1Rn0szSEjWg qfrLfk012PJFQeh3+7WQqp+19AWWfo+lj4budqOBGnC2+lWdhdWAXt3TGg+E/aUlrM8LOkaVlvCD w0vpvGOd5kQ24oClOTwjoOdq/oCeo0FHTPQEIs16/aJgwJ/ndofgg2txEGOUlrTpwEnbMpq15m2G lxrDXIusCOpiJKQLYd5XVrE+XvPr4zd87PzOHNIC2y8I6oKnOhKNV+ve8DaQy80wtyLbYdU1qOhW 2BIK6mzLIAiOsR1IOdzkM8ETblf1NM2ntcbbwyCXFgcTud5c6/DVqT6YyPHmWEZpSZ9zU6Ubs+8r nV06m8tKt3NTUn56e9L/ej+Xzk3PfABZtzhFAOMMaLXAqatN1iAawE7jt+g0ijdNA0+4QgzTbAOe ObqAPSN6dNlTG9FjDUMwWv1JcOF2fyItJ9d6CPlCyA/HM2dgpZCfqanxc3hah7Wznw33RAY9Nk/m OeJBvtCpvaKzyJDewx+WHsy61am18vXtsdYUtuYMXOCAzanhmPWxeIDXB926GoIDb5MldQal1QeP MLYjZDBzi0F+Vx/eUcVVNyBcwrdamx/jwygtgaPIDe2qErUaI1fzvaLG1Xhtc1ytVluxmSSPJRGI xkNlYLAhCJ5oCUb0hvJSajQUmoF+yng/aIL0eAg9tA/2AGm5yr5F0pQSPEzFyfXBRUE95s/Tvf4Q VgHbt78+qPdj54ZCyCpPIQXijW3OQcwVwFxehPjVyV7w7hJDF6F4nPfZENTcen88nhfnv7ekbTC6 2OEddBjEUzjlBovVoy2E5s6z1sCtuQErxDm9Blt6aEfhnf3SDE9N4UbLnwHtVIvhaZeJ4ekjYXjG iBiuTCEdxvBMYK7kDP/8x2N41jCGqy7NsDeFGyBnA63XYth3mRieMxKG/SNiOJBCOozhamAOcIbn /ngM1wxjuPbSDM9L4QbIOqCdZzE8/zIxvGAkDC8cEcPXpZAOY7gemK/jDC/68RhePIzhhkszvCSF GyCXAu0Si+Fll4nhX4yE4eCIGA6lkA5jeDkwhzjD16cY9ubpdOE5HLvo2KXLfjCvuIByvCnJ2eRj Lij88xkf0Lgy8GWRAelOeQjv2/xfJgHv4CSdxrebiP+AqpL/yzjK8PBEdWQaRKdRuQ1dfM8gCZWg 29+j42hBtKz4OHqRIaeUX53lzspH9Uk7jG/+Lj/19RxDWnAe3/jIsC4zim+W77sQZ4J97c1tFVMq qq0Ehq+wJHob/peihjp/yLe0uCba0RPtbmuKICcZ5cmI0wRz8OKOlM7UMm7/H+GlZQ4KZW5kc3Ry ZWFtCmVuZG9iago0MyAwIG9iagoyNzE2CmVuZG9iago0NCAwIG9iagooTWFjIE9TIFggMTAuOC41 IFF1YXJ0eiBQREZDb250ZXh0KQplbmRvYmoKNDUgMCBvYmoKKFBoaWwgSHVudCkKZW5kb2JqCjQ2 IDAgb2JqCihQb3dlclBvaW50KQplbmRvYmoKNDcgMCBvYmoKKEQ6MjAxMzExMDQyMTM3MjRaMDAn MDAnKQplbmRvYmoKNDggMCBvYmoKKCkKZW5kb2JqCjQ5IDAgb2JqClsgXQplbmRvYmoKMSAwIG9i ago8PCAvQXV0aG9yIDQ1IDAgUiAvUHJvZHVjZXIgNDQgMCBSIC9DcmVhdG9yIDQ2IDAgUiAvQ3Jl YXRpb25EYXRlIDQ3IDAgUiAvTW9kRGF0ZQo0NyAwIFIgL0tleXdvcmRzIDQ4IDAgUiAvQUFQTDpL ZXl3b3JkcyA0OSAwIFIgPj4KZW5kb2JqCnhyZWYKMCA1MAowMDAwMDAwMDAwIDY1NTM1IGYgCjAw MDAwNDAwMDggMDAwMDAgbiAKMDAwMDAwMDQ2OSAwMDAwMCBuIAowMDAwMDExNDU0IDAwMDAwIG4g CjAwMDAwMDAwMjIgMDAwMDAgbiAKMDAwMDAwMDQ1MCAwMDAwMCBuIAowMDAwMDAwNTczIDAwMDAw IG4gCjAwMDAwMDQ2MjcgMDAwMDAgbiAKMDAwMDAwMzQyMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAw MDAwIG4gCjAwMDAwMTY5MTUgMDAwMDAgbiAKMDAwMDAwMDY4NCAwMDAwMCBuIAowMDAwMDAzMzk5 IDAwMDAwIG4gCjAwMDAwMDM0NTYgMDAwMDAgbiAKMDAwMDAwNDYwNiAwMDAwMCBuIAowMDAwMDA2 MDA5IDAwMDAwIG4gCjAwMDAwMDQ2NjMgMDAwMDAgbiAKMDAwMDAwNTk4OCAwMDAwMCBuIAowMDAw MDA2MTE2IDAwMDAwIG4gCjAwMDAwMTE2MDggMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAow MDAwMDM2MjU4IDAwMDAwIG4gCjAwMDAwMDkzMDggMDAwMDAgbiAKMDAwMDAwNjI1NiAwMDAwMCBu IAowMDAwMDA5Mjg3IDAwMDAwIG4gCjAwMDAwMDk0MTUgMDAwMDAgbiAKMDAwMDAxMTIwNyAwMDAw MCBuIAowMDAwMDA5NTU1IDAwMDAwIG4gCjAwMDAwMTExODYgMDAwMDAgbiAKMDAwMDAxMTMxNCAw MDAwMCBuIAowMDAwMDExNTU4IDAwMDAwIG4gCjAwMDAwMTE4NzEgMDAwMDAgbiAKMDAwMDAxMjEz MSAwMDAwMCBuIAowMDAwMDE2ODk0IDAwMDAwIG4gCjAwMDAwMTgwNDYgMDAwMDAgbiAKMDAwMDAx NzMzMCAwMDAwMCBuIAowMDAwMDE4MDI2IDAwMDAwIG4gCjAwMDAwMTgyODEgMDAwMDAgbiAKMDAw MDAzNjIzNiAwMDAwMCBuIAowMDAwMDM2NzQxIDAwMDAwIG4gCjAwMDAwMzY0MjMgMDAwMDAgbiAK MDAwMDAzNjcyMSAwMDAwMCBuIAowMDAwMDM2OTkxIDAwMDAwIG4gCjAwMDAwMzk3OTcgMDAwMDAg biAKMDAwMDAzOTgxOCAwMDAwMCBuIAowMDAwMDM5ODcwIDAwMDAwIG4gCjAwMDAwMzk4OTggMDAw MDAgbiAKMDAwMDAzOTkyNyAwMDAwMCBuIAowMDAwMDM5OTY5IDAwMDAwIG4gCjAwMDAwMzk5ODgg MDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSA1MCAvUm9vdCAzMCAwIFIgL0luZm8gMSAwIFIgL0lE IFsgPDgzMTkwMTYxYzMxNzIzMjViNjU1MmI0MDg0M2Y5MGNkPgo8ODMxOTAxNjFjMzE3MjMyNWI2 NTUyYjQwODQzZjkwY2Q+IF0gPj4Kc3RhcnR4cmVmCjQwMTUzCiUlRU9GCg== --Apple-Mail=_9B3DF8EC-07F0-4F7C-AE6D-8D989DAC852F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii --Apple-Mail=_9B3DF8EC-07F0-4F7C-AE6D-8D989DAC852F-- --Apple-Mail=_3F857C31-D11A-4409-83C7-381391E8C301-- From jricher@mitre.org Mon Nov 4 13:46:34 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C486A21E81C1 for ; Mon, 4 Nov 2013 13:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.603 X-Spam-Level: X-Spam-Status: No, score=-5.603 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtP0gT28Muc1 for ; Mon, 4 Nov 2013 13:46:30 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBF021E81BB for ; Mon, 4 Nov 2013 13:46:25 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9D6CC1F077C; Mon, 4 Nov 2013 16:46:24 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 836E01F0527; Mon, 4 Nov 2013 16:46:24 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.251]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.03.0158.001; Mon, 4 Nov 2013 16:46:23 -0500 From: "Richer, Justin P." To: Nat Sakimura Thread-Topic: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 Thread-Index: AQHO2aYjcgD9QrhhQUyWBFngL5p9IpoV7yGA Date: Mon, 4 Nov 2013 21:46:23 +0000 Message-ID: <46053D48-F380-4579-BDE9-A7C1BFE1A374@mitre.org> References: <5273E5AD.7010408@gmx.net> <3F75FA0B-CAC3-439A-866B-CFE116FADA4E@ve7jtb.com> <5273F7A2.70409@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.39.63] Content-Type: multipart/alternative; boundary="_000_46053D48F3804579BDE9A7C1BFE1A374mitreorg_" MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 21:46:34 -0000 --_000_46053D48F3804579BDE9A7C1BFE1A374mitreorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Since the client isn't really supposed to be poking around inside of the cl= ient_id anyway, I think that JWS is a reasonable starting place, with JWE i= f you want to actively hide something inside of the client_id from the clie= nt (and browser and other parties that see the client_id). Most of the stuf= f that's tied to a client's configuration isn't that sensitive, in my opini= on. Also, there are other ways to have a symmetric client secret that's statele= ss beyond packing it into the client_id here. For one, since client_secrets= are also opaque to the client, you could just issue a client_secret that's= a signed JWT in its own right (or some other signed blob), letting the AS = check the signature but the client merely presenting it as a normal client_= secret. Alternatively, you could issue a bearer assertion and accomplish th= e same thing. Both of these would still need to be communicated to the clie= nt along side its client_id, the trick is coming up with a mechanism whereb= y the AS can recognize it. -- Justin On Nov 4, 2013, at 1:37 PM, Nat Sakimura > wrote: Since the client_id is supposed to be opaque, it would probably be better t= o JWE encrypt (note: all JWE encryption are integrity protected as well) by= the authorization server upon issuing it to the client. This way, we have = exactly one way of doing the things, and it works for both symmetric and as= ymmetric case. I see this more useful in the case of symmetric client secret. If the client were just using public key crypto to authenticate itself to t= he server, using the URI of the location of the client metadata as the clie= nt_id would suffice. This has an advantage of smaller client_id. 2013/11/2 Hannes Tschofenig > Hi John, thanks for the super-quick response. Am 01.11.13 19:18, schrieb John Bradley: The client_id would continue to be opaque to the client as it is now. The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and provide integrity if it is using a symmetric key (probably the simplest thing if we are talking about a single registration endpoint paired with a single AS) In more complicated scenarios where perhaps a group of AS share a single registration endpoint you probably want to use asymmetric signature then asymmetric encryption + integrity. Those are deployment decisions that need to be documented but can be transparent to teh client. Maybe it would be good to state that in the document that this is a possibl= e option without introducing further complications (other than the verifica= tion procedure is different). If the AS signs the JWT then it just needs to= compare whether the issuer field matches what it had previously put in the= re. If someone else signs the JWT then it needs to check with some trust an= chor store or something similar whether it trusts that specific issuer. Sorry to my mind it is obvious that the JWT would be integrity protected/signed for all clients including clients using asymmetric authentication to the token endpoint, and and signed+encrypted+integrity for clients using symmetric authentication. That can be made clearer. It would be good to say that because the effort is rather low and there are= benefits in doing so. It might make sense to assume the issuer is just the AS but the AS can do that without the benefit of a spec now, as there is no interoperability issue. The spec defining the JWT structure and signing and encryption methods has the most benefit when you don't have such a tight coupling between registration and AS. That is likely why Justin and I didn't think a spec was necessary for the simple case other than to show people this is possible with the existing registration spec. I think there is value in providing that information for implementers even = though it does not require new extensions or so. I am OK with strengthening the wording on signing/integrity protecting and encryption. eg if a symmetric key is included the JWT MUST be encrypted. Cool. I don't necessarily want to make any algorithm a must as that limits algorithm agility in the future. OK. Thanks for giving it a read, see you Sunday I expect. Unfortunately not since I am unable to attend the upcoming IETF meeting. De= rek will run the show. Ciao Hannes John B. On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig > wrote: Hi John, Hi all, I read your document and here a few remarks. In the dynamic client registration conference calls the topic of the stateless client was raised since there was the argument in the air that the current OAuth 2.0 RFC requires clients to be stateless due to the nature of the client identifier. It seems that you have found a way to make the client stateless with regard to the client identifier (i.e., that the authorization server does not need to store information about the client) by dumping state information in the client identifier itself. In your case you use a JWT, which is clever. Since RFC 6749 explicitly says that the client identifier string size is left undefined and that the client should avoid making assumptions about the identifier size I don't see a problem with the proposed approach. Now, there is one issue that I am wondering about. The client identifier itself is not sufficient for authorizing the client (for confidential clients). Instead, there is typically the need to have a secret. Now, the secret is not conveyed in the JWT, at least not in the way you have define it. You could of course do that and there is a document that provides prior art, see http://www.ietf.org/rfc/rfc5077 The story essentially is that the structure (JWT in your case) includes the key but of course then you have to encrypt the entire blob. In the case of public clients wouldn't you want to mandate at least a digital signature or a keyed message digest for the JWT since otherwise there is the risk that the client changes some of the parameters to impersonate someone? A few other questions: * You write: "The issuer SHOULD sign the JWT with JWS in such a way that the signature can be verified by the authorization server. " I believe what you want to say is the following: The authorization creates the client identifier (using the JWT) and the client does not parse the received content since it treats it as opaque. However, the authorization server MUST be able to process and verify received client identifiers it previously created, which requires to apply cryptographic processing when a JWT is signed (using a JWS) and when a JWT is encrypted (using a JWE). (I ignore the issue that I believe the JWT needs to be signed [for public clients] and encrypted [for confidential clients].) * You should submit the document as draft-bradley-oauth; this makes it easier to find the document. * You write: " The issuer MAY encrypt the JWT with JWE. " I think you want to be stronger by saying that JWE MUST be used when the authorization server wants to apply confidentiality protection of the JWT. While the authorization server could use other techniques as well the purpose of the document is to describe one way to accomplish the goal and therefore it makes sense to be specific. I would even go as far as suggesting specific algorithms to use, as an example. * Although not stated directly I believe you allow the client identifier to be created by a party other than the authorization server. While this would theoretically make sense wouldn't it be useful to just assume that the issuer is the authorization server? Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_46053D48F3804579BDE9A7C1BFE1A374mitreorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Since the client isn't really supposed to be poking around inside of t= he client_id anyway, I think that JWS is a reasonable starting place, with = JWE if you want to actively hide something inside of the client_id from the= client (and browser and other parties that see the client_id). Most of the stuff that's tied to a client's confi= guration isn't that sensitive, in my opinion.

Also, there are other ways to have a symmetric client secret that's statele= ss beyond packing it into the client_id here. For one, since client_secrets= are also opaque to the client, you could just issue a client_secret that's= a signed JWT in its own right (or some other signed blob), letting the AS check the signature but the client= merely presenting it as a normal client_secret. Alternatively, you could i= ssue a bearer assertion and accomplish the same thing. Both of these would = still need to be communicated to the client along side its client_id, the trick is coming up with a mechani= sm whereby the AS can recognize it. 

 -- Justin


On Nov 4, 2013, at 1:37 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Since the client_id is supposed to be opaque, it would pro= bably be better to JWE encrypt (note: all JWE encryption are integrity prot= ected as well) by the authorization server upon issuing it to the client. T= his way, we have exactly one way of doing the things, and it works for both symmetric and asymmetric case.&nbs= p;

I see this more useful in the case of symmetric client secret. 

If the client were just using public key crypto to authenticate itself= to the server, using the URI of the location of the client metadata as the= client_id would suffice. 

This has an advantage of smaller client_id. 


2013/11/2 Hannes Tschofenig &l= t;hannes.tsc= hofenig@gmx.net>
Hi John,

thanks for the super-quick response.


Am 01.11.13 19:18, schrieb John Bradley:

The client_id would continue to be opaque to the client as it is now.
The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and
provide integrity if it is using a symmetric key (probably the
simplest thing if we are talking about a single registration endpoint
paired with a single AS)  In more complicated scenarios where perhaps<= br> a group of AS share a single registration endpoint you probably want
to use asymmetric signature  then asymmetric encryption + integrit= y.
Those are deployment decisions that need to be documented but can be
transparent to teh client.

Maybe it would be good to state that in the document that this is a possibl= e option without introducing further complications (other than the verifica= tion procedure is different). If the AS signs the JWT then it just needs to= compare whether the issuer field matches what it had previously put in there. If someone else signs the JWT= then it needs to check with some trust anchor store or something similar w= hether it trusts that specific issuer.




Sorry to my mind it is obvious that the JWT would be integrity
protected/signed for all clients including clients using asymmetric
authentication to the token endpoint, and and
signed+encrypted+integrity for clients using symmetric
authentication.   That can be made clearer.

It would be good to say that because the effort is rather low and there are= benefits in doing so.



It might make sense to assume the issuer is just the AS but the AS
can do that without the benefit of a spec now, as there is no
interoperability issue.

The spec defining the JWT structure and signing and encryption
methods has the most benefit when you don't have such a tight
coupling between registration and AS.

That is likely why Justin and I didn't think a spec was necessary for
the simple case other than to show people this is possible with the
existing registration spec.

I think there is value in providing that information for implementers even = though it does not require new extensions or so.



I am OK with strengthening the wording on signing/integrity
protecting and encryption.  eg if a symmetric key is included the JWT<= br> MUST be encrypted.

Cool.


I don't necessarily want to make any algorithm a must as that limits
algorithm agility in the future.
OK.



Thanks for giving it a read, see you Sunday I expect.
Unfortunately not since I am unable to attend the upcoming IETF meeting. De= rek will run the show.

Ciao
Hannes



John B.


On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig
<hannes.t= schofenig@gmx.net> wrote:

Hi John, Hi all,

I read your document and here a few remarks.

In the dynamic client registration conference calls the topic of
the stateless client was raised since there was the argument in the
air that the current OAuth 2.0 RFC requires clients to be stateless
due to the nature of the client identifier.

It seems that you have found a way to make the client stateless
with regard to the client identifier (i.e., that the authorization
server does not need to store information about the client) by
dumping state information in the client identifier itself. In your
case you use a JWT, which is clever.

Since RFC 6749 explicitly says that the client identifier string
size is left undefined  and that the client should avoid making
assumptions about the identifier size I don't see a problem with
the proposed approach.

Now, there is one issue that I am wondering about. The client
identifier itself is not sufficient for authorizing the client (for
confidential clients). Instead, there is typically the need to have
a secret. Now, the secret is not conveyed in the JWT, at least not
in the way you have define it. You could of course do that and
there is a document that provides prior art, see
http://www.ie= tf.org/rfc/rfc5077 The story essentially is that the
structure (JWT in your case) includes the key but of course then
you have to encrypt the entire blob.

In the case of public clients wouldn't you want to mandate at least
a digital signature or a keyed message digest for the JWT since
otherwise there is the risk that the client changes some of the
parameters to impersonate someone?

A few other questions:

* You write: "The issuer SHOULD sign the JWT with JWS in such a way that the signature can be verified by the authorization server. "

I believe what you want to say is the following: The authorization
creates the client identifier (using the JWT) and the client does
not parse the received content since it treats it as opaque.
However, the authorization server MUST be able to process and
verify received client identifiers it previously created, which
requires to apply cryptographic processing when a JWT is signed
(using a JWS) and when a JWT is encrypted (using a JWE).

(I ignore the issue that I believe the JWT needs to be signed [for
public clients] and encrypted [for confidential clients].)

* You should submit the document as draft-bradley-oauth; this makes
it easier to find the document.

* You write: " The issuer MAY encrypt the JWT with JWE. "

I think you want to be stronger by saying that JWE MUST be used
when the authorization server wants to apply confidentiality
protection of the JWT. While the authorization server could use
other techniques as well the purpose of the document is to describe
one way to accomplish the goal and therefore it makes sense to be
specific.

I would even go as far as suggesting specific algorithms to use, as
an example.

* Although not stated directly I believe you allow the client
identifier to be created by a party other than the authorization
server. While this would theoretically make sense wouldn't it be
useful to just assume that the issuer is the authorization server?

Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf= .org
h= ttps://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--_000_46053D48F3804579BDE9A7C1BFE1A374mitreorg_-- From tonynad@microsoft.com Mon Nov 4 13:48:17 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E4A21E81F9 for ; Mon, 4 Nov 2013 13:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lr6oQWXc2JeV for ; Mon, 4 Nov 2013 13:48:13 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id 4885F21E81E8 for ; Mon, 4 Nov 2013 13:48:13 -0800 (PST) Received: from BY2PR03MB189.namprd03.prod.outlook.com (10.242.36.140) by BY2PR03MB189.namprd03.prod.outlook.com (10.242.36.140) with Microsoft SMTP Server (TLS) id 15.0.800.7; Mon, 4 Nov 2013 21:48:11 +0000 Received: from BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.32]) by BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.32]) with mapi id 15.00.0800.005; Mon, 4 Nov 2013 21:48:11 +0000 From: Anthony Nadalin To: Nat Sakimura , Hannes Tschofenig Thread-Topic: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 Thread-Index: AQHO1yhhDDhIjG7WR0uaCpkJVcwnaJoQrxMAgAAIsQCABOYfgIAAAliw Date: Mon, 4 Nov 2013 21:48:10 +0000 Message-ID: <80c826af712c48a3bbb731861d2ca9cc@BY2PR03MB189.namprd03.prod.outlook.com> References: <5273E5AD.7010408@gmx.net> <3F75FA0B-CAC3-439A-866B-CFE116FADA4E@ve7jtb.com> <5273F7A2.70409@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:160:3187:6e2b:e75:ce54] x-forefront-prvs: 0020414413 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(377454003)(479174003)(53754006)(51914003)(189002)(199002)(52604005)(85306002)(81686001)(77096001)(74502001)(56816003)(81816001)(47446002)(16236675002)(74662001)(31966008)(76786001)(33646001)(76796001)(76576001)(74316001)(74706001)(54356001)(74366001)(19580395003)(83322001)(19580405001)(47736001)(49866001)(80976001)(47976001)(53806001)(50986001)(59766001)(77982001)(15975445006)(63696002)(81542001)(54316002)(65816001)(56776001)(80022001)(46102001)(15202345003)(19609705001)(51856001)(79102001)(83072001)(87266001)(69226001)(19300405004)(2656002)(4396001)(74876001)(76482001)(81342001)(42262001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB189; H:BY2PR03MB189.namprd03.prod.outlook.com; CLIP:2001:67c:370:160:3187:6e2b:e75:ce54; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_80c826af712c48a3bbb731861d2ca9ccBY2PR03MB189namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 21:48:17 -0000 --_000_80c826af712c48a3bbb731861d2ca9ccBY2PR03MB189namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We need to avoid encoding secrets and authentication with client_id as auth= entication is not part of our mission From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of N= at Sakimura Sent: Monday, November 4, 2013 1:38 PM To: Hannes Tschofenig Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 Since the client_id is supposed to be opaque, it would probably be better t= o JWE encrypt (note: all JWE encryption are integrity protected as well) by= the authorization server upon issuing it to the client. This way, we have = exactly one way of doing the things, and it works for both symmetric and as= ymmetric case. I see this more useful in the case of symmetric client secret. If the client were just using public key crypto to authenticate itself to t= he server, using the URI of the location of the client metadata as the clie= nt_id would suffice. This has an advantage of smaller client_id. 2013/11/2 Hannes Tschofenig > Hi John, thanks for the super-quick response. Am 01.11.13 19:18, schrieb John Bradley: The client_id would continue to be opaque to the client as it is now. The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and provide integrity if it is using a symmetric key (probably the simplest thing if we are talking about a single registration endpoint paired with a single AS) In more complicated scenarios where perhaps a group of AS share a single registration endpoint you probably want to use asymmetric signature then asymmetric encryption + integrity. Those are deployment decisions that need to be documented but can be transparent to teh client. Maybe it would be good to state that in the document that this is a possibl= e option without introducing further complications (other than the verifica= tion procedure is different). If the AS signs the JWT then it just needs to= compare whether the issuer field matches what it had previously put in the= re. If someone else signs the JWT then it needs to check with some trust an= chor store or something similar whether it trusts that specific issuer. Sorry to my mind it is obvious that the JWT would be integrity protected/signed for all clients including clients using asymmetric authentication to the token endpoint, and and signed+encrypted+integrity for clients using symmetric authentication. That can be made clearer. It would be good to say that because the effort is rather low and there are= benefits in doing so. It might make sense to assume the issuer is just the AS but the AS can do that without the benefit of a spec now, as there is no interoperability issue. The spec defining the JWT structure and signing and encryption methods has the most benefit when you don't have such a tight coupling between registration and AS. That is likely why Justin and I didn't think a spec was necessary for the simple case other than to show people this is possible with the existing registration spec. I think there is value in providing that information for implementers even = though it does not require new extensions or so. I am OK with strengthening the wording on signing/integrity protecting and encryption. eg if a symmetric key is included the JWT MUST be encrypted. Cool. I don't necessarily want to make any algorithm a must as that limits algorithm agility in the future. OK. Thanks for giving it a read, see you Sunday I expect. Unfortunately not since I am unable to attend the upcoming IETF meeting. De= rek will run the show. Ciao Hannes John B. On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig > wrote: Hi John, Hi all, I read your document and here a few remarks. In the dynamic client registration conference calls the topic of the stateless client was raised since there was the argument in the air that the current OAuth 2.0 RFC requires clients to be stateless due to the nature of the client identifier. It seems that you have found a way to make the client stateless with regard to the client identifier (i.e., that the authorization server does not need to store information about the client) by dumping state information in the client identifier itself. In your case you use a JWT, which is clever. Since RFC 6749 explicitly says that the client identifier string size is left undefined and that the client should avoid making assumptions about the identifier size I don't see a problem with the proposed approach. Now, there is one issue that I am wondering about. The client identifier itself is not sufficient for authorizing the client (for confidential clients). Instead, there is typically the need to have a secret. Now, the secret is not conveyed in the JWT, at least not in the way you have define it. You could of course do that and there is a document that provides prior art, see http://www.ietf.org/rfc/rfc5077 The story essentially is that the structure (JWT in your case) includes the key but of course then you have to encrypt the entire blob. In the case of public clients wouldn't you want to mandate at least a digital signature or a keyed message digest for the JWT since otherwise there is the risk that the client changes some of the parameters to impersonate someone? A few other questions: * You write: "The issuer SHOULD sign the JWT with JWS in such a way that the signature can be verified by the authorization server. " I believe what you want to say is the following: The authorization creates the client identifier (using the JWT) and the client does not parse the received content since it treats it as opaque. However, the authorization server MUST be able to process and verify received client identifiers it previously created, which requires to apply cryptographic processing when a JWT is signed (using a JWS) and when a JWT is encrypted (using a JWE). (I ignore the issue that I believe the JWT needs to be signed [for public clients] and encrypted [for confidential clients].) * You should submit the document as draft-bradley-oauth; this makes it easier to find the document. * You write: " The issuer MAY encrypt the JWT with JWE. " I think you want to be stronger by saying that JWE MUST be used when the authorization server wants to apply confidentiality protection of the JWT. While the authorization server could use other techniques as well the purpose of the document is to describe one way to accomplish the goal and therefore it makes sense to be specific. I would even go as far as suggesting specific algorithms to use, as an example. * Although not stated directly I believe you allow the client identifier to be created by a party other than the authorization server. While this would theoretically make sense wouldn't it be useful to just assume that the issuer is the authorization server? Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --_000_80c826af712c48a3bbb731861d2ca9ccBY2PR03MB189namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We need to avoid encoding= secrets and authentication with client_id as authentication is not part of= our mission

 

From: oauth-= bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura
Sent: Monday, November 4, 2013 1:38 PM
To: Hannes Tschofenig
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00=

 

Since the client_id is supposed to be opaque, it wou= ld probably be better to JWE encrypt (note: all JWE encryption are integrit= y protected as well) by the authorization server upon issuing it to the cli= ent. This way, we have exactly one way of doing the things, and it works for both symmetric and asymmetric ca= se. 

 

I see this more useful in the case of symmetric clie= nt secret. 

 

If the client were just using public key crypto to a= uthenticate itself to the server, using the URI of the location of the clie= nt metadata as the client_id would suffice. 

 

This has an advantage of smaller client_id. 

 

2013/11/2 Hannes Tschofenig <hannes.tschofenig@gmx.net>= ;

Hi John,

thanks for the super-quick response.


Am 01.11.13 19:18, schrieb John Bradley:

 

The client_id would continue to be opaque to the cli= ent as it is now.
The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and
provide integrity if it is using a symmetric key (probably the
simplest thing if we are talking about a single registration endpoint
paired with a single AS)  In more complicated scenarios where perhaps<= br> a group of AS share a single registration endpoint you probably want
to use asymmetric signature  then asymmetric encryption + integrit= y.
Those are deployment decisions that need to be documented but can be
transparent to teh client.

 

Maybe it would be good to state that in the document= that this is a possible option without introducing further complications (= other than the verification procedure is different). If the AS signs the JW= T then it just needs to compare whether the issuer field matches what it had previously put in there. If someone e= lse signs the JWT then it needs to check with some trust anchor store or so= mething similar whether it trusts that specific issuer.




Sorry to my mind it is obvious that the JWT would be integrity
protected/signed for all clients including clients using asymmetric
authentication to the token endpoint, and and
signed+encrypted+integrity for clients using symmetric
authentication.   That can be made clearer.

 

It would be good to say that because the effort is r= ather low and there are benefits in doing so.

 


It might make sense to assume the issuer is just the AS but the AS
can do that without the benefit of a spec now, as there is no
interoperability issue.

The spec defining the JWT structure and signing and encryption
methods has the most benefit when you don't have such a tight
coupling between registration and AS.

That is likely why Justin and I didn't think a spec was necessary for
the simple case other than to show people this is possible with the
existing registration spec.

 

I think there is value in providing that information= for implementers even though it does not require new extensions or so.

 


I am OK with strengthening the wording on signing/integrity
protecting and encryption.  eg if a symmetric key is included the JWT<= br> MUST be encrypted.

 

Cool.

 


I don't necessarily want to make any algorithm a must as that limits
algorithm agility in the future.

OK.

 


Thanks for giving it a read, see you Sunday I expect.

Unfortunately not since I am unable to attend the up= coming IETF meeting. Derek will run the show.

Ciao
Hannes

 


John B.


On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig
<hannes.t= schofenig@gmx.net> wrote:

Hi John, Hi all,

I read your document and here a few remarks.

In the dynamic client registration conference calls the topic of
the stateless client was raised since there was the argument in the
air that the current OAuth 2.0 RFC requires clients to be stateless
due to the nature of the client identifier.

It seems that you have found a way to make the client stateless
with regard to the client identifier (i.e., that the authorization
server does not need to store information about the client) by
dumping state information in the client identifier itself. In your
case you use a JWT, which is clever.

Since RFC 6749 explicitly says that the client identifier string
size is left undefined  and that the client should avoid making
assumptions about the identifier size I don't see a problem with
the proposed approach.

Now, there is one issue that I am wondering about. The client
identifier itself is not sufficient for authorizing the client (for
confidential clients). Instead, there is typically the need to have
a secret. Now, the secret is not conveyed in the JWT, at least not
in the way you have define it. You could of course do that and
there is a document that provides prior art, see
http://www.ie= tf.org/rfc/rfc5077 The story essentially is that the
structure (JWT in your case) includes the key but of course then
you have to encrypt the entire blob.

In the case of public clients wouldn't you want to mandate at least
a digital signature or a keyed message digest for the JWT since
otherwise there is the risk that the client changes some of the
parameters to impersonate someone?

A few other questions:

* You write: "The issuer SHOULD sign the JWT with JWS in such a way that the signature can be verified by the authorization server. "

I believe what you want to say is the following: The authorization
creates the client identifier (using the JWT) and the client does
not parse the received content since it treats it as opaque.
However, the authorization server MUST be able to process and
verify received client identifiers it previously created, which
requires to apply cryptographic processing when a JWT is signed
(using a JWS) and when a JWT is encrypted (using a JWE).

(I ignore the issue that I believe the JWT needs to be signed [for
public clients] and encrypted [for confidential clients].)

* You should submit the document as draft-bradley-oauth; this makes
it easier to find the document.

* You write: " The issuer MAY encrypt the JWT with JWE. "

I think you want to be stronger by saying that JWE MUST be used
when the authorization server wants to apply confidentiality
protection of the JWT. While the authorization server could use
other techniques as well the purpose of the document is to describe
one way to accomplish the goal and therefore it makes sense to be
specific.

I would even go as far as suggesting specific algorithms to use, as
an example.

* Although not stated directly I believe you allow the client
identifier to be created by a party other than the authorization
server. While this would theoretically make sense wouldn't it be
useful to just assume that the issuer is the authorization server?

Ciao Hannes _______________________________________________ OAuth
mailing list OAuth@ietf= .org
h= ttps://www.ietf.org/mailman/listinfo/oauth

 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

--_000_80c826af712c48a3bbb731861d2ca9ccBY2PR03MB189namprd03pro_-- From sakimura@gmail.com Mon Nov 4 13:56:13 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59AF11E8212 for ; Mon, 4 Nov 2013 13:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvtCNjb+E-Sj for ; Mon, 4 Nov 2013 13:56:12 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A79DC11E813F for ; Mon, 4 Nov 2013 13:55:18 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id z5so5841963lbh.20 for ; Mon, 04 Nov 2013 13:55:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t5kkRrCy9pQoMhKvuDFEmVMskPvgbiZ2auKZ7pA4oH0=; b=wkEwoHJACs1OSA1LOC+CaK+JvyfSVOyLF9hcKmv3y2IHVaQi7s8ME8I7/f8u9mSlFM WOEcRMvLy4KARa9X7JJuoEj7XoTV+SaKRFtSw2GYwFkS2hKZL4Ta2Y7zf/yC2XdqS8H3 4MWmfDZOW2IDO15gAxHcuf5+9tFZBlv//Wj+DaF7A25xahWpXYH8NuEv0JKbU5pPEqBE BdVKy6gQ13iVJowJtSdLuzRFvJreRKSmqbqMspT281KbvD2bQntQxqS44Wfkw1h5bMXW FJ5AH/Bx3p3Wlu//IqINODMx6wSqDfx7Qs8FGoXSiyYrAvjAXawiKUvDjMVdtcj2T/PP Iu0A== MIME-Version: 1.0 X-Received: by 10.152.27.129 with SMTP id t1mr2926071lag.37.1383602117606; Mon, 04 Nov 2013 13:55:17 -0800 (PST) Received: by 10.112.134.38 with HTTP; Mon, 4 Nov 2013 13:55:17 -0800 (PST) In-Reply-To: <46053D48-F380-4579-BDE9-A7C1BFE1A374@mitre.org> References: <5273E5AD.7010408@gmx.net> <3F75FA0B-CAC3-439A-866B-CFE116FADA4E@ve7jtb.com> <5273F7A2.70409@gmx.net> <46053D48-F380-4579-BDE9-A7C1BFE1A374@mitre.org> Date: Tue, 5 Nov 2013 06:55:17 +0900 Message-ID: From: Nat Sakimura To: "Richer, Justin P." Content-Type: multipart/alternative; boundary=089e0160bcb8bb04ce04ea60f8b7 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 21:56:13 -0000 --089e0160bcb8bb04ce04ea60f8b7 Content-Type: text/plain; charset=ISO-8859-1 2013/11/5 Richer, Justin P. > Since the client isn't really supposed to be poking around inside of the > client_id anyway, I think that JWS is a reasonable starting place, with JWE > if you want to actively hide something inside of the client_id from the > client (and browser and other parties that see the client_id). Most of the > stuff that's tied to a client's configuration isn't that sensitive, in my > opinion. > It may or may not. It depends, really. Switching between encrypted and just signed depending on the cases seems to be a bit of overhead, though I agree that signing is a bit easier. > > Also, there are other ways to have a symmetric client secret that's > stateless beyond packing it into the client_id here. For one, since > client_secrets are also opaque to the client, you could just issue a > client_secret that's a signed JWT in its own right (or some other signed > blob), letting the AS check the signature but the client merely presenting > it as a normal client_secret. Alternatively, you could issue a bearer > assertion and accomplish the same thing. Both of these would still need to > be communicated to the client along side its client_id, the trick is coming > up with a mechanism whereby the AS can recognize it. > That's probably more reasonable. Linking two JWT with sub claim or something like that. > > -- Justin > > > > On Nov 4, 2013, at 1:37 PM, Nat Sakimura wrote: > > Since the client_id is supposed to be opaque, it would probably be > better to JWE encrypt (note: all JWE encryption are integrity protected as > well) by the authorization server upon issuing it to the client. This way, > we have exactly one way of doing the things, and it works for both > symmetric and asymmetric case. > > I see this more useful in the case of symmetric client secret. > > If the client were just using public key crypto to authenticate itself > to the server, using the URI of the location of the client metadata as the > client_id would suffice. > > This has an advantage of smaller client_id. > > > 2013/11/2 Hannes Tschofenig > >> Hi John, >> >> thanks for the super-quick response. >> >> >> Am 01.11.13 19:18, schrieb John Bradley: >> >> The client_id would continue to be opaque to the client as it is now. >>> The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and >>> provide integrity if it is using a symmetric key (probably the >>> simplest thing if we are talking about a single registration endpoint >>> paired with a single AS) In more complicated scenarios where perhaps >>> a group of AS share a single registration endpoint you probably want >>> to use asymmetric signature then asymmetric encryption + integrity. >>> Those are deployment decisions that need to be documented but can be >>> transparent to teh client. >>> >> >> Maybe it would be good to state that in the document that this is a >> possible option without introducing further complications (other than the >> verification procedure is different). If the AS signs the JWT then it just >> needs to compare whether the issuer field matches what it had previously >> put in there. If someone else signs the JWT then it needs to check with >> some trust anchor store or something similar whether it trusts that >> specific issuer. >> >> >> >> >>> Sorry to my mind it is obvious that the JWT would be integrity >>> protected/signed for all clients including clients using asymmetric >>> authentication to the token endpoint, and and >>> signed+encrypted+integrity for clients using symmetric >>> authentication. That can be made clearer. >>> >> >> It would be good to say that because the effort is rather low and there >> are benefits in doing so. >> >> >> >>> It might make sense to assume the issuer is just the AS but the AS >>> can do that without the benefit of a spec now, as there is no >>> interoperability issue. >>> >>> The spec defining the JWT structure and signing and encryption >>> methods has the most benefit when you don't have such a tight >>> coupling between registration and AS. >>> >>> That is likely why Justin and I didn't think a spec was necessary for >>> the simple case other than to show people this is possible with the >>> existing registration spec. >>> >> >> I think there is value in providing that information for implementers >> even though it does not require new extensions or so. >> >> >> >>> I am OK with strengthening the wording on signing/integrity >>> protecting and encryption. eg if a symmetric key is included the JWT >>> MUST be encrypted. >>> >> >> Cool. >> >> >>> I don't necessarily want to make any algorithm a must as that limits >>> algorithm agility in the future. >>> >> OK. >> >> >> >>> Thanks for giving it a read, see you Sunday I expect. >>> >> Unfortunately not since I am unable to attend the upcoming IETF meeting. >> Derek will run the show. >> >> Ciao >> Hannes >> >> >> >>> John B. >>> >>> >>> On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig >>> wrote: >>> >>> Hi John, Hi all, >>>> >>>> I read your document and here a few remarks. >>>> >>>> In the dynamic client registration conference calls the topic of >>>> the stateless client was raised since there was the argument in the >>>> air that the current OAuth 2.0 RFC requires clients to be stateless >>>> due to the nature of the client identifier. >>>> >>>> It seems that you have found a way to make the client stateless >>>> with regard to the client identifier (i.e., that the authorization >>>> server does not need to store information about the client) by >>>> dumping state information in the client identifier itself. In your >>>> case you use a JWT, which is clever. >>>> >>>> Since RFC 6749 explicitly says that the client identifier string >>>> size is left undefined and that the client should avoid making >>>> assumptions about the identifier size I don't see a problem with >>>> the proposed approach. >>>> >>>> Now, there is one issue that I am wondering about. The client >>>> identifier itself is not sufficient for authorizing the client (for >>>> confidential clients). Instead, there is typically the need to have >>>> a secret. Now, the secret is not conveyed in the JWT, at least not >>>> in the way you have define it. You could of course do that and >>>> there is a document that provides prior art, see >>>> http://www.ietf.org/rfc/rfc5077 The story essentially is that the >>>> structure (JWT in your case) includes the key but of course then >>>> you have to encrypt the entire blob. >>>> >>>> In the case of public clients wouldn't you want to mandate at least >>>> a digital signature or a keyed message digest for the JWT since >>>> otherwise there is the risk that the client changes some of the >>>> parameters to impersonate someone? >>>> >>>> A few other questions: >>>> >>>> * You write: "The issuer SHOULD sign the JWT with JWS in such a way >>>> that the signature can be verified by the authorization server. " >>>> >>>> I believe what you want to say is the following: The authorization >>>> creates the client identifier (using the JWT) and the client does >>>> not parse the received content since it treats it as opaque. >>>> However, the authorization server MUST be able to process and >>>> verify received client identifiers it previously created, which >>>> requires to apply cryptographic processing when a JWT is signed >>>> (using a JWS) and when a JWT is encrypted (using a JWE). >>>> >>>> (I ignore the issue that I believe the JWT needs to be signed [for >>>> public clients] and encrypted [for confidential clients].) >>>> >>>> * You should submit the document as draft-bradley-oauth; this makes >>>> it easier to find the document. >>>> >>>> * You write: " The issuer MAY encrypt the JWT with JWE. " >>>> >>>> I think you want to be stronger by saying that JWE MUST be used >>>> when the authorization server wants to apply confidentiality >>>> protection of the JWT. While the authorization server could use >>>> other techniques as well the purpose of the document is to describe >>>> one way to accomplish the goal and therefore it makes sense to be >>>> specific. >>>> >>>> I would even go as far as suggesting specific algorithms to use, as >>>> an example. >>>> >>>> * Although not stated directly I believe you allow the client >>>> identifier to be created by a party other than the authorization >>>> server. While this would theoretically make sense wouldn't it be >>>> useful to just assume that the issuer is the authorization server? >>>> >>>> Ciao Hannes _______________________________________________ OAuth >>>> mailing list OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --089e0160bcb8bb04ce04ea60f8b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



2013/11/5 Richer, Justin P. <jricher@mitre.org>
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Since the client isn't really supposed to be poking around inside = of the client_id anyway, I think that JWS is a reasonable starting place, w= ith JWE if you want to actively hide something inside of the client_id from= the client (and browser and other parties that see the client_id). Most of the stuff that's tied to a client'= ;s configuration isn't that sensitive, in my opinion.

It may or may not. It depends, really. Switching= between encrypted and just signed depending on the cases seems to be a bit= of overhead, though I agree that signing is a bit easier. =A0
=A0

Also, there are other ways to have a symmetric client secret that's sta= teless beyond packing it into the client_id here. For one, since client_sec= rets are also opaque to the client, you could just issue a client_secret th= at's a signed JWT in its own right (or some other signed blob), letting the AS check the signature but the client= merely presenting it as a normal client_secret. Alternatively, you could i= ssue a bearer assertion and accomplish the same thing. Both of these would = still need to be communicated to the client along side its client_id, the trick is coming up with a mechani= sm whereby the AS can recognize it.=A0

That's probably more reasonable. Linking two JWT with sub claim or so= mething like that. =A0

=A0-- Jus= tin



On Nov 4, 2013, at 1:37 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Since the client_id is supposed to be opaque, it would pro= bably be better to JWE encrypt (note: all JWE encryption are integrity prot= ected as well) by the authorization server upon issuing it to the client. T= his way, we have exactly one way of doing the things, and it works for both symmetric and asymmetric case.=A0

I see this more useful in the case of symmetric client secret.=A0

If the client were just using public key crypto to authenticate itself= to the server, using the URI of the location of the client metadata as the= client_id would suffice.=A0

This has an advantage of smaller client_id.=A0


2013/11/2 Hannes Tschofenig &l= t;hannes.tsc= hofenig@gmx.net>
Hi John,

thanks for the super-quick response.


Am 01.11.13 19:18, schrieb John Bradley:

The client_id would continue to be opaque to the client as it is now.
The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and
provide integrity if it is using a symmetric key (probably the
simplest thing if we are talking about a single registration endpoint
paired with a single AS) =A0In more complicated scenarios where perhaps
a group of AS share a single registration endpoint you probably want
to use asymmetric signature =A0then asymmetric encryption + integrity.
Those are deployment decisions that need to be documented but can be
transparent to teh client.

Maybe it would be good to state that in the document that this is a possibl= e option without introducing further complications (other than the verifica= tion procedure is different). If the AS signs the JWT then it just needs to= compare whether the issuer field matches what it had previously put in there. If someone else signs the JWT= then it needs to check with some trust anchor store or something similar w= hether it trusts that specific issuer.




Sorry to my mind it is obvious that the JWT would be integrity
protected/signed for all clients including clients using asymmetric
authentication to the token endpoint, and and
signed+encrypted+integrity for clients using symmetric
authentication. =A0 That can be made clearer.

It would be good to say that because the effort is rather low and there are= benefits in doing so.



It might make sense to assume the issuer is just the AS but the AS
can do that without the benefit of a spec now, as there is no
interoperability issue.

The spec defining the JWT structure and signing and encryption
methods has the most benefit when you don't have such a tight
coupling between registration and AS.

That is likely why Justin and I didn't think a spec was necessary for the simple case other than to show people this is possible with the
existing registration spec.

I think there is value in providing that information for implementers even = though it does not require new extensions or so.



I am OK with strengthening the wording on signing/integrity
protecting and encryption. =A0eg if a symmetric key is included the JWT
MUST be encrypted.

Cool.


I don't necessarily want to make any algorithm a must as that limits algorithm agility in the future.
OK.



Thanks for giving it a read, see you Sunday I expect.
Unfortunately not since I am unable to attend the upcoming IETF meeting. De= rek will run the show.

Ciao
Hannes



John B.


On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig
<hannes.t= schofenig@gmx.net> wrote:

Hi John, Hi all,

I read your document and here a few remarks.

In the dynamic client registration conference calls the topic of
the stateless client was raised since there was the argument in the
air that the current OAuth 2.0 RFC requires clients to be stateless
due to the nature of the client identifier.

It seems that you have found a way to make the client stateless
with regard to the client identifier (i.e., that the authorization
server does not need to store information about the client) by
dumping state information in the client identifier itself. In your
case you use a JWT, which is clever.

Since RFC 6749 explicitly says that the client identifier string
size is left undefined =A0and that the client should avoid making
assumptions about the identifier size I don't see a problem with
the proposed approach.

Now, there is one issue that I am wondering about. The client
identifier itself is not sufficient for authorizing the client (for
confidential clients). Instead, there is typically the need to have
a secret. Now, the secret is not conveyed in the JWT, at least not
in the way you have define it. You could of course do that and
there is a document that provides prior art, see
http://www.ie= tf.org/rfc/rfc5077 The story essentially is that the
structure (JWT in your case) includes the key but of course then
you have to encrypt the entire blob.

In the case of public clients wouldn't you want to mandate at least
a digital signature or a keyed message digest for the JWT since
otherwise there is the risk that the client changes some of the
parameters to impersonate someone?

A few other questions:

* You write: "The issuer SHOULD sign the JWT with JWS in such a way that the signature can be verified by the authorization server. "

I believe what you want to say is the following: The authorization
creates the client identifier (using the JWT) and the client does
not parse the received content since it treats it as opaque.
However, the authorization server MUST be able to process and
verify received client identifiers it previously created, which
requires to apply cryptographic processing when a JWT is signed
(using a JWS) and when a JWT is encrypted (using a JWE).

(I ignore the issue that I believe the JWT needs to be signed [for
public clients] and encrypted [for confidential clients].)

* You should submit the document as draft-bradley-oauth; this makes
it easier to find the document.

* You write: " The issuer MAY encrypt the JWT with JWE. "

I think you want to be stronger by saying that JWE MUST be used
when the authorization server wants to apply confidentiality
protection of the JWT. While the authorization server could use
other techniques as well the purpose of the document is to describe
one way to accomplish the goal and therefore it makes sense to be
specific.

I would even go as far as suggesting specific algorithms to use, as
an example.

* Although not stated directly I believe you allow the client
identifier to be created by a party other than the authorization
server. While this would theoretically make sense wouldn't it be
useful to just assume that the issuer is the authorization server?

Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf= .org
h= ttps://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




--
Nat Sakimura= (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--089e0160bcb8bb04ce04ea60f8b7-- From ve7jtb@ve7jtb.com Mon Nov 4 13:57:18 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0139521F9FB0 for ; Mon, 4 Nov 2013 13:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxAWcHQw-Bu2 for ; Mon, 4 Nov 2013 13:57:13 -0800 (PST) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by ietfa.amsl.com (Postfix) with ESMTP id AAED911E8225 for ; Mon, 4 Nov 2013 13:56:15 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id kx10so7451041pab.26 for ; Mon, 04 Nov 2013 13:56:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=0mL441YE8VeswdS+R2mver/B2BG4dhnQ03Y7a3HlKhk=; b=ffymtfJjyFyNhyGzS0LuMOHCShs9GEKpjFdsVwJGI2qLJAaii6k4D6gUsEr50hsO8k M16dAUGJOrivZ4ov5O3YoRWs3KxJN5MvRhMgM8hu+WNPfh+6jjQUTPe0eXZfB3QazV09 EpAHxTL3nwJxkwQypmqDh+3IbsW8/SKtX3ZWY45tBCzB5aZ8ivwHfjx2qo8V35mJGk+f m5sm/ASlxfl9xc6Rvyu9XgAXZ6oOatg1SToCp+HcZ/i2v2DcwD3loEVhvFUMLJvWLv9Q Vg8yvzMAkLXITOfWfK0G5oygd329gE19Ffk1FqPncIDNAC81vCsJIT0lTliwkCdPIEq/ IPWA== X-Gm-Message-State: ALoCoQk1isQnx2YHmjQt8+3GPwnjpoMyXy9eThpC7t3XP/X2heBkjuHEOHItuotHugjJFy9kf58L X-Received: by 10.66.162.195 with SMTP id yc3mr19562288pab.64.1383602175279; Mon, 04 Nov 2013 13:56:15 -0800 (PST) Received: from [192.168.6.17] (199-91-80-194.ip.van.radiant.net. [199.91.80.194]) by mx.google.com with ESMTPSA id xe9sm35518692pab.0.2013.11.04.13.56.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 13:56:13 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_8F3582FE-7BCD-4CBD-8FE9-F9334F3D5AAB"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: John Bradley In-Reply-To: Date: Mon, 4 Nov 2013 13:56:03 -0800 Message-Id: References: <5273E5AD.7010408@gmx.net> <3F75FA0B-CAC3-439A-866B-CFE116FADA4E@ve7jtb.com> <5273F7A2.70409@gmx.net> To: Nat Sakimura X-Mailer: Apple Mail (2.1816) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 21:57:18 -0000 --Apple-Mail=_8F3582FE-7BCD-4CBD-8FE9-F9334F3D5AAB Content-Type: multipart/alternative; boundary="Apple-Mail=_A16C11C7-4EFD-427A-BF7F-5AEDE3E8372C" --Apple-Mail=_A16C11C7-4EFD-427A-BF7F-5AEDE3E8372C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 If the AS is using asymmetric encryption you need to both sign and then = encrypt as anyone can encrypt.=20 Yes if the client has a TLS cert you could use a jwk_uri to keep the = size down. John B. On Nov 4, 2013, at 1:37 PM, Nat Sakimura wrote: > Since the client_id is supposed to be opaque, it would probably be = better to JWE encrypt (note: all JWE encryption are integrity protected = as well) by the authorization server upon issuing it to the client. This = way, we have exactly one way of doing the things, and it works for both = symmetric and asymmetric case.=20 >=20 > I see this more useful in the case of symmetric client secret.=20 >=20 > If the client were just using public key crypto to authenticate itself = to the server, using the URI of the location of the client metadata as = the client_id would suffice.=20 >=20 > This has an advantage of smaller client_id.=20 >=20 >=20 > 2013/11/2 Hannes Tschofenig > Hi John, >=20 > thanks for the super-quick response. >=20 >=20 > Am 01.11.13 19:18, schrieb John Bradley: >=20 > The client_id would continue to be opaque to the client as it is now. > The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and > provide integrity if it is using a symmetric key (probably the > simplest thing if we are talking about a single registration endpoint > paired with a single AS) In more complicated scenarios where perhaps > a group of AS share a single registration endpoint you probably want > to use asymmetric signature then asymmetric encryption + integrity. > Those are deployment decisions that need to be documented but can be > transparent to teh client. >=20 > Maybe it would be good to state that in the document that this is a = possible option without introducing further complications (other than = the verification procedure is different). If the AS signs the JWT then = it just needs to compare whether the issuer field matches what it had = previously put in there. If someone else signs the JWT then it needs to = check with some trust anchor store or something similar whether it = trusts that specific issuer. >=20 >=20 >=20 >=20 > Sorry to my mind it is obvious that the JWT would be integrity > protected/signed for all clients including clients using asymmetric > authentication to the token endpoint, and and > signed+encrypted+integrity for clients using symmetric > authentication. That can be made clearer. >=20 > It would be good to say that because the effort is rather low and = there are benefits in doing so. >=20 >=20 >=20 > It might make sense to assume the issuer is just the AS but the AS > can do that without the benefit of a spec now, as there is no > interoperability issue. >=20 > The spec defining the JWT structure and signing and encryption > methods has the most benefit when you don't have such a tight > coupling between registration and AS. >=20 > That is likely why Justin and I didn't think a spec was necessary for > the simple case other than to show people this is possible with the > existing registration spec. >=20 > I think there is value in providing that information for implementers = even though it does not require new extensions or so. >=20 >=20 >=20 > I am OK with strengthening the wording on signing/integrity > protecting and encryption. eg if a symmetric key is included the JWT > MUST be encrypted. >=20 > Cool. >=20 >=20 > I don't necessarily want to make any algorithm a must as that limits > algorithm agility in the future. > OK. >=20 >=20 >=20 > Thanks for giving it a read, see you Sunday I expect. > Unfortunately not since I am unable to attend the upcoming IETF = meeting. Derek will run the show. >=20 > Ciao > Hannes >=20 >=20 >=20 > John B. >=20 >=20 > On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig > wrote: >=20 > Hi John, Hi all, >=20 > I read your document and here a few remarks. >=20 > In the dynamic client registration conference calls the topic of > the stateless client was raised since there was the argument in the > air that the current OAuth 2.0 RFC requires clients to be stateless > due to the nature of the client identifier. >=20 > It seems that you have found a way to make the client stateless > with regard to the client identifier (i.e., that the authorization > server does not need to store information about the client) by > dumping state information in the client identifier itself. In your > case you use a JWT, which is clever. >=20 > Since RFC 6749 explicitly says that the client identifier string > size is left undefined and that the client should avoid making > assumptions about the identifier size I don't see a problem with > the proposed approach. >=20 > Now, there is one issue that I am wondering about. The client > identifier itself is not sufficient for authorizing the client (for > confidential clients). Instead, there is typically the need to have > a secret. Now, the secret is not conveyed in the JWT, at least not > in the way you have define it. You could of course do that and > there is a document that provides prior art, see > http://www.ietf.org/rfc/rfc5077 The story essentially is that the > structure (JWT in your case) includes the key but of course then > you have to encrypt the entire blob. >=20 > In the case of public clients wouldn't you want to mandate at least > a digital signature or a keyed message digest for the JWT since > otherwise there is the risk that the client changes some of the > parameters to impersonate someone? >=20 > A few other questions: >=20 > * You write: "The issuer SHOULD sign the JWT with JWS in such a way > that the signature can be verified by the authorization server. " >=20 > I believe what you want to say is the following: The authorization > creates the client identifier (using the JWT) and the client does > not parse the received content since it treats it as opaque. > However, the authorization server MUST be able to process and > verify received client identifiers it previously created, which > requires to apply cryptographic processing when a JWT is signed > (using a JWS) and when a JWT is encrypted (using a JWE). >=20 > (I ignore the issue that I believe the JWT needs to be signed [for > public clients] and encrypted [for confidential clients].) >=20 > * You should submit the document as draft-bradley-oauth; this makes > it easier to find the document. >=20 > * You write: " The issuer MAY encrypt the JWT with JWE. " >=20 > I think you want to be stronger by saying that JWE MUST be used > when the authorization server wants to apply confidentiality > protection of the JWT. While the authorization server could use > other techniques as well the purpose of the document is to describe > one way to accomplish the goal and therefore it makes sense to be > specific. >=20 > I would even go as far as suggesting specific algorithms to use, as > an example. >=20 > * Although not stated directly I believe you allow the client > identifier to be created by a party other than the authorization > server. While this would theoretically make sense wouldn't it be > useful to just assume that the issuer is the authorization server? >=20 > Ciao Hannes _______________________________________________ OAuth > mailing list OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en --Apple-Mail=_A16C11C7-4EFD-427A-BF7F-5AEDE3E8372C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 If the AS is using asymmetric encryption you need to both sign and then encrypt as anyone can encrypt. 

Yes if the client has a TLS cert you could use a jwk_uri to keep the size down.

John B.

On Nov 4, 2013, at 1:37 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Since the client_id is supposed to be opaque, it would probably be better to JWE encrypt (note: all JWE encryption are integrity protected as well) by the authorization server upon issuing it to the client. This way, we have exactly one way of doing the things, and it works for both symmetric and asymmetric case. 

I see this more useful in the case of symmetric client secret. 

If the client were just using public key crypto to authenticate itself to the server, using the URI of the location of the client metadata as the client_id would suffice. 

This has an advantage of smaller client_id. 


2013/11/2 Hannes Tschofenig <hannes.tschofenig@gmx.net>
Hi John,

thanks for the super-quick response.


Am 01.11.13 19:18, schrieb John Bradley:

The client_id would continue to be opaque to the client as it is now.
The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and
provide integrity if it is using a symmetric key (probably the
simplest thing if we are talking about a single registration endpoint
paired with a single AS)  In more complicated scenarios where perhaps
a group of AS share a single registration endpoint you probably want
to use asymmetric signature  then asymmetric encryption + integrity.
Those are deployment decisions that need to be documented but can be
transparent to teh client.

Maybe it would be good to state that in the document that this is a possible option without introducing further complications (other than the verification procedure is different). If the AS signs the JWT then it just needs to compare whether the issuer field matches what it had previously put in there. If someone else signs the JWT then it needs to check with some trust anchor store or something similar whether it trusts that specific issuer.




Sorry to my mind it is obvious that the JWT would be integrity
protected/signed for all clients including clients using asymmetric
authentication to the token endpoint, and and
signed+encrypted+integrity for clients using symmetric
authentication.   That can be made clearer.

It would be good to say that because the effort is rather low and there are benefits in doing so.



It might make sense to assume the issuer is just the AS but the AS
can do that without the benefit of a spec now, as there is no
interoperability issue.

The spec defining the JWT structure and signing and encryption
methods has the most benefit when you don't have such a tight
coupling between registration and AS.

That is likely why Justin and I didn't think a spec was necessary for
the simple case other than to show people this is possible with the
existing registration spec.

I think there is value in providing that information for implementers even though it does not require new extensions or so.



I am OK with strengthening the wording on signing/integrity
protecting and encryption.  eg if a symmetric key is included the JWT
MUST be encrypted.

Cool.


I don't necessarily want to make any algorithm a must as that limits
algorithm agility in the future.
OK.



Thanks for giving it a read, see you Sunday I expect.
Unfortunately not since I am unable to attend the upcoming IETF meeting. Derek will run the show.

Ciao
Hannes



John B.


On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig
<hannes.tschofenig@gmx.net> wrote:

Hi John, Hi all,

I read your document and here a few remarks.

In the dynamic client registration conference calls the topic of
the stateless client was raised since there was the argument in the
air that the current OAuth 2.0 RFC requires clients to be stateless
due to the nature of the client identifier.

It seems that you have found a way to make the client stateless
with regard to the client identifier (i.e., that the authorization
server does not need to store information about the client) by
dumping state information in the client identifier itself. In your
case you use a JWT, which is clever.

Since RFC 6749 explicitly says that the client identifier string
size is left undefined  and that the client should avoid making
assumptions about the identifier size I don't see a problem with
the proposed approach.

Now, there is one issue that I am wondering about. The client
identifier itself is not sufficient for authorizing the client (for
confidential clients). Instead, there is typically the need to have
a secret. Now, the secret is not conveyed in the JWT, at least not
in the way you have define it. You could of course do that and
there is a document that provides prior art, see
http://www.ietf.org/rfc/rfc5077 The story essentially is that the
structure (JWT in your case) includes the key but of course then
you have to encrypt the entire blob.

In the case of public clients wouldn't you want to mandate at least
a digital signature or a keyed message digest for the JWT since
otherwise there is the risk that the client changes some of the
parameters to impersonate someone?

A few other questions:

* You write: "The issuer SHOULD sign the JWT with JWS in such a way
that the signature can be verified by the authorization server. "

I believe what you want to say is the following: The authorization
creates the client identifier (using the JWT) and the client does
not parse the received content since it treats it as opaque.
However, the authorization server MUST be able to process and
verify received client identifiers it previously created, which
requires to apply cryptographic processing when a JWT is signed
(using a JWS) and when a JWT is encrypted (using a JWE).

(I ignore the issue that I believe the JWT needs to be signed [for
public clients] and encrypted [for confidential clients].)

* You should submit the document as draft-bradley-oauth; this makes
it easier to find the document.

* You write: " The issuer MAY encrypt the JWT with JWE. "

I think you want to be stronger by saying that JWE MUST be used
when the authorization server wants to apply confidentiality
protection of the JWT. While the authorization server could use
other techniques as well the purpose of the document is to describe
one way to accomplish the goal and therefore it makes sense to be
specific.

I would even go as far as suggesting specific algorithms to use, as
an example.

* Although not stated directly I believe you allow the client
identifier to be created by a party other than the authorization
server. While this would theoretically make sense wouldn't it be
useful to just assume that the issuer is the authorization server?

Ciao Hannes _______________________________________________ OAuth
mailing list OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--Apple-Mail=_A16C11C7-4EFD-427A-BF7F-5AEDE3E8372C-- --Apple-Mail=_8F3582FE-7BCD-4CBD-8FE9-F9334F3D5AAB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMTA0MjE1NjAzWjAjBgkqhkiG9w0BCQQxFgQU/YTe3ib1 Kw+QsX7tGrbcTkSJn3EwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAc1oOZi6J43+rHv38fJiX4BhQ14Aayqni+vAB5K00 yvDA4TaN1pzrpCGnqngCl6WkJLVuBfmlR1cWVjKnoXT1Ur/4kwYRXHfsaslrRiQoVwtQ1zDy4qkp Z3wKOcFLkq6K15i8uEUXDucYkiqdILREx7tpMD4MiIGd9yjfP04bh9Qcrkv4vkbx3UJHRkHvhzMH xO9g/8IcD2aRTebTELmdWRKEOcBpRSHlI/7dA+33Rmm9AIoLRHyBDj/bAyg552UnZG6Fe0im7TXQ 2Sed84yivKM0Mgi8Zvtjdf5p94gkuaEWPwSFzWqZ5aY2Co/NnUbJsQ0gSAN5EcxKJQe63T/NEgAA AAAAAA== --Apple-Mail=_8F3582FE-7BCD-4CBD-8FE9-F9334F3D5AAB-- From sakimura@gmail.com Mon Nov 4 13:57:23 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46D621E80AA for ; Mon, 4 Nov 2013 13:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FB2nW6rwYmSN for ; Mon, 4 Nov 2013 13:57:22 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0419121F9A3B for ; Mon, 4 Nov 2013 13:56:51 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id er20so1477523lab.3 for ; Mon, 04 Nov 2013 13:56:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JxwRBW3ofctkWu2LquCCXaWEmi2Km6vMLd/Amvs4YCc=; b=IspXxg6y9pLUii9ZrGN17U1USLQ+ORjUCWhakUtgrMvIFaaIVtsWqqMuvKi4zU0wGh wk4LV+R6Z8iUzNoDaAHKkL6Rx8dN/ZHoGy2zC6slMidfVhp/TIHBjgbApFIyxxafBAnO wA/63ln/3pg3DRlrgwdMzKbOhYP3RcOvJdWSEnMb5Kqv17c7xfYxSv+Y04HJDzj/OLoW 8iebvrUYxDio6jGlWdJ14dCyict6SZz/i3Y1P13CsChDroVR+meIsfkgIsfsj+QofMzf EZYtAq/8907RUSZp7DqZ5wDuotbwNyR6tR+gF4b7s/RJLKn0OKrh25KONGnSW3Wr4q8s rrOw== MIME-Version: 1.0 X-Received: by 10.112.200.170 with SMTP id jt10mr3118538lbc.10.1383602210880; Mon, 04 Nov 2013 13:56:50 -0800 (PST) Received: by 10.112.134.38 with HTTP; Mon, 4 Nov 2013 13:56:50 -0800 (PST) In-Reply-To: <80c826af712c48a3bbb731861d2ca9cc@BY2PR03MB189.namprd03.prod.outlook.com> References: <5273E5AD.7010408@gmx.net> <3F75FA0B-CAC3-439A-866B-CFE116FADA4E@ve7jtb.com> <5273F7A2.70409@gmx.net> <80c826af712c48a3bbb731861d2ca9cc@BY2PR03MB189.namprd03.prod.outlook.com> Date: Tue, 5 Nov 2013 06:56:50 +0900 Message-ID: From: Nat Sakimura To: Anthony Nadalin Content-Type: multipart/alternative; boundary=001a11c265b84a457204ea60fe57 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 21:57:23 -0000 --001a11c265b84a457204ea60fe57 Content-Type: text/plain; charset=ISO-8859-1 See my reply to Justin. BTW, is not the client authentication one of the pain point for the server that we want to solve statelessly? 2013/11/5 Anthony Nadalin > We need to avoid encoding secrets and authentication with client_id as > authentication is not part of our mission > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Nat Sakimura > *Sent:* Monday, November 4, 2013 1:38 PM > *To:* Hannes Tschofenig > *Cc:* oauth@ietf.org WG > *Subject:* Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 > > > > Since the client_id is supposed to be opaque, it would probably be better > to JWE encrypt (note: all JWE encryption are integrity protected as well) > by the authorization server upon issuing it to the client. This way, we > have exactly one way of doing the things, and it works for both symmetric > and asymmetric case. > > > > I see this more useful in the case of symmetric client secret. > > > > If the client were just using public key crypto to authenticate itself to > the server, using the URI of the location of the client metadata as the > client_id would suffice. > > > > This has an advantage of smaller client_id. > > > > 2013/11/2 Hannes Tschofenig > > Hi John, > > thanks for the super-quick response. > > > Am 01.11.13 19:18, schrieb John Bradley: > > > > The client_id would continue to be opaque to the client as it is now. > The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and > provide integrity if it is using a symmetric key (probably the > simplest thing if we are talking about a single registration endpoint > paired with a single AS) In more complicated scenarios where perhaps > a group of AS share a single registration endpoint you probably want > to use asymmetric signature then asymmetric encryption + integrity. > Those are deployment decisions that need to be documented but can be > transparent to teh client. > > > > Maybe it would be good to state that in the document that this is a > possible option without introducing further complications (other than the > verification procedure is different). If the AS signs the JWT then it just > needs to compare whether the issuer field matches what it had previously > put in there. If someone else signs the JWT then it needs to check with > some trust anchor store or something similar whether it trusts that > specific issuer. > > > > > Sorry to my mind it is obvious that the JWT would be integrity > protected/signed for all clients including clients using asymmetric > authentication to the token endpoint, and and > signed+encrypted+integrity for clients using symmetric > authentication. That can be made clearer. > > > > It would be good to say that because the effort is rather low and there > are benefits in doing so. > > > > > It might make sense to assume the issuer is just the AS but the AS > can do that without the benefit of a spec now, as there is no > interoperability issue. > > The spec defining the JWT structure and signing and encryption > methods has the most benefit when you don't have such a tight > coupling between registration and AS. > > That is likely why Justin and I didn't think a spec was necessary for > the simple case other than to show people this is possible with the > existing registration spec. > > > > I think there is value in providing that information for implementers even > though it does not require new extensions or so. > > > > > I am OK with strengthening the wording on signing/integrity > protecting and encryption. eg if a symmetric key is included the JWT > MUST be encrypted. > > > > Cool. > > > > > I don't necessarily want to make any algorithm a must as that limits > algorithm agility in the future. > > OK. > > > > > Thanks for giving it a read, see you Sunday I expect. > > Unfortunately not since I am unable to attend the upcoming IETF meeting. > Derek will run the show. > > Ciao > Hannes > > > > > John B. > > > On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig > wrote: > > Hi John, Hi all, > > I read your document and here a few remarks. > > In the dynamic client registration conference calls the topic of > the stateless client was raised since there was the argument in the > air that the current OAuth 2.0 RFC requires clients to be stateless > due to the nature of the client identifier. > > It seems that you have found a way to make the client stateless > with regard to the client identifier (i.e., that the authorization > server does not need to store information about the client) by > dumping state information in the client identifier itself. In your > case you use a JWT, which is clever. > > Since RFC 6749 explicitly says that the client identifier string > size is left undefined and that the client should avoid making > assumptions about the identifier size I don't see a problem with > the proposed approach. > > Now, there is one issue that I am wondering about. The client > identifier itself is not sufficient for authorizing the client (for > confidential clients). Instead, there is typically the need to have > a secret. Now, the secret is not conveyed in the JWT, at least not > in the way you have define it. You could of course do that and > there is a document that provides prior art, see > http://www.ietf.org/rfc/rfc5077 The story essentially is that the > structure (JWT in your case) includes the key but of course then > you have to encrypt the entire blob. > > In the case of public clients wouldn't you want to mandate at least > a digital signature or a keyed message digest for the JWT since > otherwise there is the risk that the client changes some of the > parameters to impersonate someone? > > A few other questions: > > * You write: "The issuer SHOULD sign the JWT with JWS in such a way > that the signature can be verified by the authorization server. " > > I believe what you want to say is the following: The authorization > creates the client identifier (using the JWT) and the client does > not parse the received content since it treats it as opaque. > However, the authorization server MUST be able to process and > verify received client identifiers it previously created, which > requires to apply cryptographic processing when a JWT is signed > (using a JWS) and when a JWT is encrypted (using a JWE). > > (I ignore the issue that I believe the JWT needs to be signed [for > public clients] and encrypted [for confidential clients].) > > * You should submit the document as draft-bradley-oauth; this makes > it easier to find the document. > > * You write: " The issuer MAY encrypt the JWT with JWE. " > > I think you want to be stronger by saying that JWE MUST be used > when the authorization server wants to apply confidentiality > protection of the JWT. While the authorization server could use > other techniques as well the purpose of the document is to describe > one way to accomplish the goal and therefore it makes sense to be > specific. > > I would even go as far as suggesting specific algorithms to use, as > an example. > > * Although not stated directly I believe you allow the client > identifier to be created by a party other than the authorization > server. While this would theoretically make sense wouldn't it be > useful to just assume that the issuer is the authorization server? > > Ciao Hannes _______________________________________________ OAuth > mailing list OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Nat Sakimura (=nat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c265b84a457204ea60fe57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
See my reply to Justin.=A0

BTW, is not = the client authentication one of the pain point for the server that we want= to solve statelessly?=A0


2013/11/5 Anthony Nadalin <tonynad@microsoft.com>

We need to avoid encoding= secrets and authentication with client_id as authentication is not part of= our mission

=A0

From: oauth-bounces@ietf.or= g [mailto:o= auth-bounces@ietf.org] On Behalf Of Nat Sakimura
Sent: Monday, November 4, 2013 1:38 PM
To: Hannes Tschofenig
Cc: oauth@ietf.o= rg WG
Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00

=A0

Since the client_id is supposed to be opaque, it wou= ld probably be better to JWE encrypt (note: all JWE encryption are integrit= y protected as well) by the authorization server upon issuing it to the cli= ent. This way, we have exactly one way of doing the things, and it works for both symmetric and asymmetric ca= se.=A0

=A0

I see this more useful in the case of symmetric clie= nt secret.=A0

=A0

If the client were just using public key crypto to a= uthenticate itself to the server, using the URI of the location of the clie= nt metadata as the client_id would suffice.=A0

=A0

This has an advantage of smaller client_id.=A0

=A0

2013/11/2 Hannes Tschofenig <hannes.tschofenig@gmx.net>= ;

Hi John,

thanks for the super-quick response.


Am 01.11.13 19:18, schrieb John Bradley:

=A0

The client_id would continue to be opaque to the cli= ent as it is now.
The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and
provide integrity if it is using a symmetric key (probably the
simplest thing if we are talking about a single registration endpoint
paired with a single AS) =A0In more complicated scenarios where perhaps
a group of AS share a single registration endpoint you probably want
to use asymmetric signature =A0then asymmetric encryption + integrity.
Those are deployment decisions that need to be documented but can be
transparent to teh client.

=A0

Maybe it would be good to state that in the document= that this is a possible option without introducing further complications (= other than the verification procedure is different). If the AS signs the JW= T then it just needs to compare whether the issuer field matches what it had previously put in there. If someone e= lse signs the JWT then it needs to check with some trust anchor store or so= mething similar whether it trusts that specific issuer.




Sorry to my mind it is obvious that the JWT would be integrity
protected/signed for all clients including clients using asymmetric
authentication to the token endpoint, and and
signed+encrypted+integrity for clients using symmetric
authentication. =A0 That can be made clearer.

=A0

It would be good to say that because the effort is r= ather low and there are benefits in doing so.

=A0


It might make sense to assume the issuer is just the AS but the AS
can do that without the benefit of a spec now, as there is no
interoperability issue.

The spec defining the JWT structure and signing and encryption
methods has the most benefit when you don't have such a tight
coupling between registration and AS.

That is likely why Justin and I didn't think a spec was necessary for the simple case other than to show people this is possible with the
existing registration spec.

=A0

I think there is value in providing that information= for implementers even though it does not require new extensions or so.<= /u>

=A0


I am OK with strengthening the wording on signing/integrity
protecting and encryption. =A0eg if a symmetric key is included the JWT
MUST be encrypted.

=A0

Cool.

=A0


I don't necessarily want to make any algorithm a must as that limits algorithm agility in the future.

OK.

=A0


Thanks for giving it a read, see you Sunday I expect.

Unfortunately not since I am unable to attend the up= coming IETF meeting. Derek will run the show.

Ciao
Hannes

=A0


John B.


On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig
<hannes.t= schofenig@gmx.net> wrote:

Hi John, Hi all,

I read your document and here a few remarks.

In the dynamic client registration conference calls the topic of
the stateless client was raised since there was the argument in the
air that the current OAuth 2.0 RFC requires clients to be stateless
due to the nature of the client identifier.

It seems that you have found a way to make the client stateless
with regard to the client identifier (i.e., that the authorization
server does not need to store information about the client) by
dumping state information in the client identifier itself. In your
case you use a JWT, which is clever.

Since RFC 6749 explicitly says that the client identifier string
size is left undefined =A0and that the client should avoid making
assumptions about the identifier size I don't see a problem with
the proposed approach.

Now, there is one issue that I am wondering about. The client
identifier itself is not sufficient for authorizing the client (for
confidential clients). Instead, there is typically the need to have
a secret. Now, the secret is not conveyed in the JWT, at least not
in the way you have define it. You could of course do that and
there is a document that provides prior art, see
http://www.ie= tf.org/rfc/rfc5077 The story essentially is that the
structure (JWT in your case) includes the key but of course then
you have to encrypt the entire blob.

In the case of public clients wouldn't you want to mandate at least
a digital signature or a keyed message digest for the JWT since
otherwise there is the risk that the client changes some of the
parameters to impersonate someone?

A few other questions:

* You write: "The issuer SHOULD sign the JWT with JWS in such a way that the signature can be verified by the authorization server. "

I believe what you want to say is the following: The authorization
creates the client identifier (using the JWT) and the client does
not parse the received content since it treats it as opaque.
However, the authorization server MUST be able to process and
verify received client identifiers it previously created, which
requires to apply cryptographic processing when a JWT is signed
(using a JWS) and when a JWT is encrypted (using a JWE).

(I ignore the issue that I believe the JWT needs to be signed [for
public clients] and encrypted [for confidential clients].)

* You should submit the document as draft-bradley-oauth; this makes
it easier to find the document.

* You write: " The issuer MAY encrypt the JWT with JWE. "

I think you want to be stronger by saying that JWE MUST be used
when the authorization server wants to apply confidentiality
protection of the JWT. While the authorization server could use
other techniques as well the purpose of the document is to describe
one way to accomplish the goal and therefore it makes sense to be
specific.

I would even go as far as suggesting specific algorithms to use, as
an example.

* Although not stated directly I believe you allow the client
identifier to be created by a party other than the authorization
server. While this would theoretically make sense wouldn't it be
useful to just assume that the issuer is the authorization server?

Ciao Hannes _______________________________________________ OAuth
mailing list OAuth@ietf= .org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=A0


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en




--
Nat Sakimura= (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a11c265b84a457204ea60fe57-- From sakimura@gmail.com Mon Nov 4 13:58:30 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E447E21F9DF6 for ; Mon, 4 Nov 2013 13:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id St+ma0tq4gOr for ; Mon, 4 Nov 2013 13:58:29 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 072B721F9F8F for ; Mon, 4 Nov 2013 13:58:19 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id u14so5935983lbd.15 for ; Mon, 04 Nov 2013 13:58:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R6il9qOSR4u4x1EIPP+lG4HFh+lKs4HFkVsft+f2w7w=; b=mycbcn+JLIHpyiDKvyQKzRoPhOOnZgy/hMA8ywVV3G4iK6JTd9KaSjmvt0wDV4XT/g DzJCKAVQzfXl9FETM0ubz7caapy44nfRwWDdLEXyQoQZJglmdu+pzkqfwEYUV6tYzTJn PsxG8xWiCaNcCw90I6fG3l0fz3ApivFychYvAXeJnPSyRQoEb22N3wkgkBNsVM2Mb5Ju 6niB0k+ZOdytpSDhPrgn/nxwpLEWAIDsxVeXApjFWojgXicCpQzXBtR9dfwWKGJjIL/r ls09PghIQwtI8WbJbMOWXIInvHff0WHf482zhzmjmwsgmJrrDgBgaIHe+6vwkAOQ2CzP 2Y5g== MIME-Version: 1.0 X-Received: by 10.152.88.3 with SMTP id bc3mr6001253lab.4.1383602298928; Mon, 04 Nov 2013 13:58:18 -0800 (PST) Received: by 10.112.134.38 with HTTP; Mon, 4 Nov 2013 13:58:18 -0800 (PST) In-Reply-To: References: <5273E5AD.7010408@gmx.net> <3F75FA0B-CAC3-439A-866B-CFE116FADA4E@ve7jtb.com> <5273F7A2.70409@gmx.net> Date: Tue, 5 Nov 2013 06:58:18 +0900 Message-ID: From: Nat Sakimura To: John Bradley Content-Type: multipart/alternative; boundary=001a11c355dc89c3b904ea6103b8 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 21:58:31 -0000 --001a11c355dc89c3b904ea6103b8 Content-Type: text/plain; charset=ISO-8859-1 I was assuming that the AS uses symmetric encryption as it is faster and it just needs to be encrypted and decoded by itself. 2013/11/5 John Bradley > If the AS is using asymmetric encryption you need to both sign and then > encrypt as anyone can encrypt. > > Yes if the client has a TLS cert you could use a jwk_uri to keep the size > down. > > John B. > > On Nov 4, 2013, at 1:37 PM, Nat Sakimura wrote: > > Since the client_id is supposed to be opaque, it would probably be better > to JWE encrypt (note: all JWE encryption are integrity protected as well) > by the authorization server upon issuing it to the client. This way, we > have exactly one way of doing the things, and it works for both symmetric > and asymmetric case. > > I see this more useful in the case of symmetric client secret. > > If the client were just using public key crypto to authenticate itself to > the server, using the URI of the location of the client metadata as the > client_id would suffice. > > This has an advantage of smaller client_id. > > > 2013/11/2 Hannes Tschofenig > >> Hi John, >> >> thanks for the super-quick response. >> >> >> Am 01.11.13 19:18, schrieb John Bradley: >> >> The client_id would continue to be opaque to the client as it is now. >>> The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and >>> provide integrity if it is using a symmetric key (probably the >>> simplest thing if we are talking about a single registration endpoint >>> paired with a single AS) In more complicated scenarios where perhaps >>> a group of AS share a single registration endpoint you probably want >>> to use asymmetric signature then asymmetric encryption + integrity. >>> Those are deployment decisions that need to be documented but can be >>> transparent to teh client. >>> >> >> Maybe it would be good to state that in the document that this is a >> possible option without introducing further complications (other than the >> verification procedure is different). If the AS signs the JWT then it just >> needs to compare whether the issuer field matches what it had previously >> put in there. If someone else signs the JWT then it needs to check with >> some trust anchor store or something similar whether it trusts that >> specific issuer. >> >> >> >> >>> Sorry to my mind it is obvious that the JWT would be integrity >>> protected/signed for all clients including clients using asymmetric >>> authentication to the token endpoint, and and >>> signed+encrypted+integrity for clients using symmetric >>> authentication. That can be made clearer. >>> >> >> It would be good to say that because the effort is rather low and there >> are benefits in doing so. >> >> >> >>> It might make sense to assume the issuer is just the AS but the AS >>> can do that without the benefit of a spec now, as there is no >>> interoperability issue. >>> >>> The spec defining the JWT structure and signing and encryption >>> methods has the most benefit when you don't have such a tight >>> coupling between registration and AS. >>> >>> That is likely why Justin and I didn't think a spec was necessary for >>> the simple case other than to show people this is possible with the >>> existing registration spec. >>> >> >> I think there is value in providing that information for implementers >> even though it does not require new extensions or so. >> >> >> >>> I am OK with strengthening the wording on signing/integrity >>> protecting and encryption. eg if a symmetric key is included the JWT >>> MUST be encrypted. >>> >> >> Cool. >> >> >>> I don't necessarily want to make any algorithm a must as that limits >>> algorithm agility in the future. >>> >> OK. >> >> >> >>> Thanks for giving it a read, see you Sunday I expect. >>> >> Unfortunately not since I am unable to attend the upcoming IETF meeting. >> Derek will run the show. >> >> Ciao >> Hannes >> >> >> >>> John B. >>> >>> >>> On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig >>> wrote: >>> >>> Hi John, Hi all, >>>> >>>> I read your document and here a few remarks. >>>> >>>> In the dynamic client registration conference calls the topic of >>>> the stateless client was raised since there was the argument in the >>>> air that the current OAuth 2.0 RFC requires clients to be stateless >>>> due to the nature of the client identifier. >>>> >>>> It seems that you have found a way to make the client stateless >>>> with regard to the client identifier (i.e., that the authorization >>>> server does not need to store information about the client) by >>>> dumping state information in the client identifier itself. In your >>>> case you use a JWT, which is clever. >>>> >>>> Since RFC 6749 explicitly says that the client identifier string >>>> size is left undefined and that the client should avoid making >>>> assumptions about the identifier size I don't see a problem with >>>> the proposed approach. >>>> >>>> Now, there is one issue that I am wondering about. The client >>>> identifier itself is not sufficient for authorizing the client (for >>>> confidential clients). Instead, there is typically the need to have >>>> a secret. Now, the secret is not conveyed in the JWT, at least not >>>> in the way you have define it. You could of course do that and >>>> there is a document that provides prior art, see >>>> http://www.ietf.org/rfc/rfc5077 The story essentially is that the >>>> structure (JWT in your case) includes the key but of course then >>>> you have to encrypt the entire blob. >>>> >>>> In the case of public clients wouldn't you want to mandate at least >>>> a digital signature or a keyed message digest for the JWT since >>>> otherwise there is the risk that the client changes some of the >>>> parameters to impersonate someone? >>>> >>>> A few other questions: >>>> >>>> * You write: "The issuer SHOULD sign the JWT with JWS in such a way >>>> that the signature can be verified by the authorization server. " >>>> >>>> I believe what you want to say is the following: The authorization >>>> creates the client identifier (using the JWT) and the client does >>>> not parse the received content since it treats it as opaque. >>>> However, the authorization server MUST be able to process and >>>> verify received client identifiers it previously created, which >>>> requires to apply cryptographic processing when a JWT is signed >>>> (using a JWS) and when a JWT is encrypted (using a JWE). >>>> >>>> (I ignore the issue that I believe the JWT needs to be signed [for >>>> public clients] and encrypted [for confidential clients].) >>>> >>>> * You should submit the document as draft-bradley-oauth; this makes >>>> it easier to find the document. >>>> >>>> * You write: " The issuer MAY encrypt the JWT with JWE. " >>>> >>>> I think you want to be stronger by saying that JWE MUST be used >>>> when the authorization server wants to apply confidentiality >>>> protection of the JWT. While the authorization server could use >>>> other techniques as well the purpose of the document is to describe >>>> one way to accomplish the goal and therefore it makes sense to be >>>> specific. >>>> >>>> I would even go as far as suggesting specific algorithms to use, as >>>> an example. >>>> >>>> * Although not stated directly I believe you allow the client >>>> identifier to be created by a party other than the authorization >>>> server. While this would theoretically make sense wouldn't it be >>>> useful to just assume that the issuer is the authorization server? >>>> >>>> Ciao Hannes _______________________________________________ OAuth >>>> mailing list OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c355dc89c3b904ea6103b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I was assuming that the AS uses symmetric encryption as it= is faster and it just needs to be encrypted and decoded by itself.=A0


2013/11/5 Jo= hn Bradley <ve7jtb@ve7jtb.com>
If the A= S is using asymmetric encryption you need to both sign and then encrypt as = anyone can encrypt.=A0

Yes if the client has a TLS cert you could use a jwk_uri to = keep the size down.

John B.

On Nov 4, 2013, at 1:37 PM, Nat Sakimura <sakimura@gmail.com> wr= ote:

Since the client_id is supposed to be opaque, it would probably be better = to JWE encrypt (note: all JWE encryption are integrity protected as well) b= y the authorization server upon issuing it to the client. This way, we have= exactly one way of doing the things, and it works for both symmetric and a= symmetric case.=A0

I see this more useful in the case of symmetric client secre= t.=A0

If the client were just using public key cry= pto to authenticate itself to the server, using the URI of the location of = the client metadata as the client_id would suffice.=A0

This has an advantage of smaller client_id.=A0


2013/11/2 = Hannes Tschofenig <hannes.tschofenig@gmx.net>
Hi John,

thanks for the super-quick response.


Am 01.11.13 19:18, schrieb John Bradley:

The client_id would continue to be opaque to the client as it is now.
The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and
provide integrity if it is using a symmetric key (probably the
simplest thing if we are talking about a single registration endpoint
paired with a single AS) =A0In more complicated scenarios where perhaps
a group of AS share a single registration endpoint you probably want
to use asymmetric signature =A0then asymmetric encryption + integrity.
Those are deployment decisions that need to be documented but can be
transparent to teh client.

Maybe it would be good to state that in the document that this is a possibl= e option without introducing further complications (other than the verifica= tion procedure is different). If the AS signs the JWT then it just needs to= compare whether the issuer field matches what it had previously put in the= re. If someone else signs the JWT then it needs to check with some trust an= chor store or something similar whether it trusts that specific issuer.



Sorry to my mind it is obvious that the JWT would be integrity
protected/signed for all clients including clients using asymmetric
authentication to the token endpoint, and and
signed+encrypted+integrity for clients using symmetric
authentication. =A0 That can be made clearer.

It would be good to say that because the effort is rather low and there are= benefits in doing so.



It might make sense to assume the issuer is just the AS but the AS
can do that without the benefit of a spec now, as there is no
interoperability issue.

The spec defining the JWT structure and signing and encryption
methods has the most benefit when you don't have such a tight
coupling between registration and AS.

That is likely why Justin and I didn't think a spec was necessary for the simple case other than to show people this is possible with the
existing registration spec.

I think there is value in providing that information for implementers even = though it does not require new extensions or so.



I am OK with strengthening the wording on signing/integrity
protecting and encryption. =A0eg if a symmetric key is included the JWT
MUST be encrypted.

Cool.


I don't necessarily want to make any algorithm a must as that limits algorithm agility in the future.
OK.



Thanks for giving it a read, see you Sunday I expect.
Unfortunately not since I am unable to attend the upcoming IETF meeting. De= rek will run the show.

Ciao
Hannes



John B.


On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig
<hannes.t= schofenig@gmx.net> wrote:

Hi John, Hi all,

I read your document and here a few remarks.

In the dynamic client registration conference calls the topic of
the stateless client was raised since there was the argument in the
air that the current OAuth 2.0 RFC requires clients to be stateless
due to the nature of the client identifier.

It seems that you have found a way to make the client stateless
with regard to the client identifier (i.e., that the authorization
server does not need to store information about the client) by
dumping state information in the client identifier itself. In your
case you use a JWT, which is clever.

Since RFC 6749 explicitly says that the client identifier string
size is left undefined =A0and that the client should avoid making
assumptions about the identifier size I don't see a problem with
the proposed approach.

Now, there is one issue that I am wondering about. The client
identifier itself is not sufficient for authorizing the client (for
confidential clients). Instead, there is typically the need to have
a secret. Now, the secret is not conveyed in the JWT, at least not
in the way you have define it. You could of course do that and
there is a document that provides prior art, see
http://www.ie= tf.org/rfc/rfc5077 The story essentially is that the
structure (JWT in your case) includes the key but of course then
you have to encrypt the entire blob.

In the case of public clients wouldn't you want to mandate at least
a digital signature or a keyed message digest for the JWT since
otherwise there is the risk that the client changes some of the
parameters to impersonate someone?

A few other questions:

* You write: "The issuer SHOULD sign the JWT with JWS in such a way that the signature can be verified by the authorization server. "

I believe what you want to say is the following: The authorization
creates the client identifier (using the JWT) and the client does
not parse the received content since it treats it as opaque.
However, the authorization server MUST be able to process and
verify received client identifiers it previously created, which
requires to apply cryptographic processing when a JWT is signed
(using a JWS) and when a JWT is encrypted (using a JWE).

(I ignore the issue that I believe the JWT needs to be signed [for
public clients] and encrypted [for confidential clients].)

* You should submit the document as draft-bradley-oauth; this makes
it easier to find the document.

* You write: " The issuer MAY encrypt the JWT with JWE. "

I think you want to be stronger by saying that JWE MUST be used
when the authorization server wants to apply confidentiality
protection of the JWT. While the authorization server could use
other techniques as well the purpose of the document is to describe
one way to accomplish the goal and therefore it makes sense to be
specific.

I would even go as far as suggesting specific algorithms to use, as
an example.

* Although not stated directly I believe you allow the client
identifier to be created by a party other than the authorization
server. While this would theoretically make sense wouldn't it be
useful to just assume that the issuer is the authorization server?

Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf= .org
h= ttps://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en




--
Nat Sakimura (=3Dnat)
Chairman, Open= ID Foundation
htt= p://nat.sakimura.org/
@_nat_en
--001a11c355dc89c3b904ea6103b8-- From tonynad@microsoft.com Mon Nov 4 14:01:19 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B1821E81B4 for ; Mon, 4 Nov 2013 14:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gETIBFcQvWd0 for ; Mon, 4 Nov 2013 14:01:14 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA8B21F9A40 for ; Mon, 4 Nov 2013 14:01:14 -0800 (PST) Received: from BY2PR03MB189.namprd03.prod.outlook.com (10.242.36.140) by BY2PR03MB192.namprd03.prod.outlook.com (10.242.36.144) with Microsoft SMTP Server (TLS) id 15.0.800.7; Mon, 4 Nov 2013 22:01:12 +0000 Received: from BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.32]) by BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.32]) with mapi id 15.00.0800.005; Mon, 4 Nov 2013 22:01:12 +0000 From: Anthony Nadalin To: Nat Sakimura Thread-Topic: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 Thread-Index: AQHO1yhhDDhIjG7WR0uaCpkJVcwnaJoQrxMAgAAIsQCABOYfgIAAAliwgAAC+wCAAABmwA== Date: Mon, 4 Nov 2013 22:01:11 +0000 Message-ID: <4c6d0f3169bd440995e511280b4b34a3@BY2PR03MB189.namprd03.prod.outlook.com> References: <5273E5AD.7010408@gmx.net> <3F75FA0B-CAC3-439A-866B-CFE116FADA4E@ve7jtb.com> <5273F7A2.70409@gmx.net> <80c826af712c48a3bbb731861d2ca9cc@BY2PR03MB189.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:160:3187:6e2b:e75:ce54] x-forefront-prvs: 0020414413 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(52604005)(377454003)(479174003)(53754006)(51914003)(24454002)(81542001)(19300405004)(19580395003)(33646001)(19609705001)(1411001)(54356001)(15202345003)(74706001)(74316001)(83322001)(80976001)(51856001)(74876001)(83072001)(50986001)(65816001)(4396001)(49866001)(79102001)(56816003)(81816001)(16236675002)(76576001)(76796001)(76786001)(56776001)(85306002)(74502001)(77096001)(15975445006)(69226001)(81342001)(76482001)(74366001)(47976001)(47736001)(63696002)(19580405001)(53806001)(47446002)(77982001)(74662001)(31966008)(80022001)(81686001)(59766001)(46102001)(87266001)(54316002)(2656002)(42262001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB192; H:BY2PR03MB189.namprd03.prod.outlook.com; CLIP:2001:67c:370:160:3187:6e2b:e75:ce54; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_4c6d0f3169bd440995e511280b4b34a3BY2PR03MB189namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:01:19 -0000 --_000_4c6d0f3169bd440995e511280b4b34a3BY2PR03MB189namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have mechanisms to do this it's not in our scope to start to encode the = client_id with authentication information From: Nat Sakimura [mailto:sakimura@gmail.com] Sent: Monday, November 4, 2013 1:57 PM To: Anthony Nadalin Cc: Hannes Tschofenig; oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 See my reply to Justin. BTW, is not the client authentication one of the pain point for the server = that we want to solve statelessly? 2013/11/5 Anthony Nadalin > We need to avoid encoding secrets and authentication with client_id as auth= entication is not part of our mission From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Nat Sakimura Sent: Monday, November 4, 2013 1:38 PM To: Hannes Tschofenig Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 Since the client_id is supposed to be opaque, it would probably be better t= o JWE encrypt (note: all JWE encryption are integrity protected as well) by= the authorization server upon issuing it to the client. This way, we have = exactly one way of doing the things, and it works for both symmetric and as= ymmetric case. I see this more useful in the case of symmetric client secret. If the client were just using public key crypto to authenticate itself to t= he server, using the URI of the location of the client metadata as the clie= nt_id would suffice. This has an advantage of smaller client_id. 2013/11/2 Hannes Tschofenig > Hi John, thanks for the super-quick response. Am 01.11.13 19:18, schrieb John Bradley: The client_id would continue to be opaque to the client as it is now. The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and provide integrity if it is using a symmetric key (probably the simplest thing if we are talking about a single registration endpoint paired with a single AS) In more complicated scenarios where perhaps a group of AS share a single registration endpoint you probably want to use asymmetric signature then asymmetric encryption + integrity. Those are deployment decisions that need to be documented but can be transparent to teh client. Maybe it would be good to state that in the document that this is a possibl= e option without introducing further complications (other than the verifica= tion procedure is different). If the AS signs the JWT then it just needs to= compare whether the issuer field matches what it had previously put in the= re. If someone else signs the JWT then it needs to check with some trust an= chor store or something similar whether it trusts that specific issuer. Sorry to my mind it is obvious that the JWT would be integrity protected/signed for all clients including clients using asymmetric authentication to the token endpoint, and and signed+encrypted+integrity for clients using symmetric authentication. That can be made clearer. It would be good to say that because the effort is rather low and there are= benefits in doing so. It might make sense to assume the issuer is just the AS but the AS can do that without the benefit of a spec now, as there is no interoperability issue. The spec defining the JWT structure and signing and encryption methods has the most benefit when you don't have such a tight coupling between registration and AS. That is likely why Justin and I didn't think a spec was necessary for the simple case other than to show people this is possible with the existing registration spec. I think there is value in providing that information for implementers even = though it does not require new extensions or so. I am OK with strengthening the wording on signing/integrity protecting and encryption. eg if a symmetric key is included the JWT MUST be encrypted. Cool. I don't necessarily want to make any algorithm a must as that limits algorithm agility in the future. OK. Thanks for giving it a read, see you Sunday I expect. Unfortunately not since I am unable to attend the upcoming IETF meeting. De= rek will run the show. Ciao Hannes John B. On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig > wrote: Hi John, Hi all, I read your document and here a few remarks. In the dynamic client registration conference calls the topic of the stateless client was raised since there was the argument in the air that the current OAuth 2.0 RFC requires clients to be stateless due to the nature of the client identifier. It seems that you have found a way to make the client stateless with regard to the client identifier (i.e., that the authorization server does not need to store information about the client) by dumping state information in the client identifier itself. In your case you use a JWT, which is clever. Since RFC 6749 explicitly says that the client identifier string size is left undefined and that the client should avoid making assumptions about the identifier size I don't see a problem with the proposed approach. Now, there is one issue that I am wondering about. The client identifier itself is not sufficient for authorizing the client (for confidential clients). Instead, there is typically the need to have a secret. Now, the secret is not conveyed in the JWT, at least not in the way you have define it. You could of course do that and there is a document that provides prior art, see http://www.ietf.org/rfc/rfc5077 The story essentially is that the structure (JWT in your case) includes the key but of course then you have to encrypt the entire blob. In the case of public clients wouldn't you want to mandate at least a digital signature or a keyed message digest for the JWT since otherwise there is the risk that the client changes some of the parameters to impersonate someone? A few other questions: * You write: "The issuer SHOULD sign the JWT with JWS in such a way that the signature can be verified by the authorization server. " I believe what you want to say is the following: The authorization creates the client identifier (using the JWT) and the client does not parse the received content since it treats it as opaque. However, the authorization server MUST be able to process and verify received client identifiers it previously created, which requires to apply cryptographic processing when a JWT is signed (using a JWS) and when a JWT is encrypted (using a JWE). (I ignore the issue that I believe the JWT needs to be signed [for public clients] and encrypted [for confidential clients].) * You should submit the document as draft-bradley-oauth; this makes it easier to find the document. * You write: " The issuer MAY encrypt the JWT with JWE. " I think you want to be stronger by saying that JWE MUST be used when the authorization server wants to apply confidentiality protection of the JWT. While the authorization server could use other techniques as well the purpose of the document is to describe one way to accomplish the goal and therefore it makes sense to be specific. I would even go as far as suggesting specific algorithms to use, as an example. * Although not stated directly I believe you allow the client identifier to be created by a party other than the authorization server. While this would theoretically make sense wouldn't it be useful to just assume that the issuer is the authorization server? Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --_000_4c6d0f3169bd440995e511280b4b34a3BY2PR03MB189namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have mechanisms to do = this it’s not in our scope to start to encode the client_id with auth= entication information

 

From: Nat Sa= kimura [mailto:sakimura@gmail.com]
Sent: Monday, November 4, 2013 1:57 PM
To: Anthony Nadalin
Cc: Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00=

 

See my reply to Justin. 

 

BTW, is not the client authentication one of the pai= n point for the server that we want to solve statelessly? <= /p>

 

2013/11/5 Anthony Nadalin <tonynad@microsoft.com>

We need to avoid encoding secrets and a= uthentication with client_id as authentication is not part of our mission

 

From: oauth-bounces@i= etf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura
Sent: Monday, November 4, 2013 1:38 PM
To: Hannes Tschofenig
Cc: oauth@ietf.o= rg WG
Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00

 

Since the client_id is supposed to be opaque, it would probably be= better to JWE encrypt (note: all JWE encryption are integrity protected as= well) by the authorization server upon issuing it to the client. This way, we have exactly one way of doing the t= hings, and it works for both symmetric and asymmetric case. 

 

I see this more useful in the case of symmetric client secret.&nbs= p;

 

If the client were just using public key crypto to authenticate it= self to the server, using the URI of the location of the client metadata as= the client_id would suffice. 

 

This has an advantage of smaller client_id. 

 

2013/11/2 Hannes Tschofenig <hannes.tschofenig@gmx.net>

Hi John,

thanks for the super-quick response.


Am 01.11.13 19:18, schrieb John Bradley:

 

The client_id would continue to be opaque to the client as it is n= ow.
The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and
provide integrity if it is using a symmetric key (probably the
simplest thing if we are talking about a single registration endpoint
paired with a single AS)  In more complicated scenarios where perhaps<= br> a group of AS share a single registration endpoint you probably want
to use asymmetric signature  then asymmetric encryption + integrit= y.
Those are deployment decisions that need to be documented but can be
transparent to teh client.

 

Maybe it would be good to state that in the document that this is = a possible option without introducing further complications (other than the= verification procedure is different). If the AS signs the JWT then it just needs to compare whether the issuer f= ield matches what it had previously put in there. If someone else signs the= JWT then it needs to check with some trust anchor store or something simil= ar whether it trusts that specific issuer.

 


Sorry to my mind it is obvious that the JWT would be integrity
protected/signed for all clients including clients using asymmetric
authentication to the token endpoint, and and
signed+encrypted+integrity for clients using symmetric
authentication.   That can be made clearer.

 

It would be good to say that because the effort is rather low and = there are benefits in doing so.

 


It might make sense to assume the issuer is just the AS but the AS
can do that without the benefit of a spec now, as there is no
interoperability issue.

The spec defining the JWT structure and signing and encryption
methods has the most benefit when you don't have such a tight
coupling between registration and AS.

That is likely why Justin and I didn't think a spec was necessary for
the simple case other than to show people this is possible with the
existing registration spec.

 

I think there is value in providing that information for implement= ers even though it does not require new extensions or so.

 


I am OK with strengthening the wording on signing/integrity
protecting and encryption.  eg if a symmetric key is included the JWT<= br> MUST be encrypted.

 

Cool.

 


I don't necessarily want to make any algorithm a must as that limits
algorithm agility in the future.

OK.

 


Thanks for giving it a read, see you Sunday I expect.

Unfortunately not since I am unable to attend the upcoming IETF me= eting. Derek will run the show.

Ciao
Hannes

 


John B.


On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig
<hannes.t= schofenig@gmx.net> wrote:

Hi John, Hi all,

I read your document and here a few remarks.

In the dynamic client registration conference calls the topic of
the stateless client was raised since there was the argument in the
air that the current OAuth 2.0 RFC requires clients to be stateless
due to the nature of the client identifier.

It seems that you have found a way to make the client stateless
with regard to the client identifier (i.e., that the authorization
server does not need to store information about the client) by
dumping state information in the client identifier itself. In your
case you use a JWT, which is clever.

Since RFC 6749 explicitly says that the client identifier string
size is left undefined  and that the client should avoid making
assumptions about the identifier size I don't see a problem with
the proposed approach.

Now, there is one issue that I am wondering about. The client
identifier itself is not sufficient for authorizing the client (for
confidential clients). Instead, there is typically the need to have
a secret. Now, the secret is not conveyed in the JWT, at least not
in the way you have define it. You could of course do that and
there is a document that provides prior art, see
http://www.ie= tf.org/rfc/rfc5077 The story essentially is that the
structure (JWT in your case) includes the key but of course then
you have to encrypt the entire blob.

In the case of public clients wouldn't you want to mandate at least
a digital signature or a keyed message digest for the JWT since
otherwise there is the risk that the client changes some of the
parameters to impersonate someone?

A few other questions:

* You write: "The issuer SHOULD sign the JWT with JWS in such a way that the signature can be verified by the authorization server. "

I believe what you want to say is the following: The authorization
creates the client identifier (using the JWT) and the client does
not parse the received content since it treats it as opaque.
However, the authorization server MUST be able to process and
verify received client identifiers it previously created, which
requires to apply cryptographic processing when a JWT is signed
(using a JWS) and when a JWT is encrypted (using a JWE).

(I ignore the issue that I believe the JWT needs to be signed [for
public clients] and encrypted [for confidential clients].)

* You should submit the document as draft-bradley-oauth; this makes
it easier to find the document.

* You write: " The issuer MAY encrypt the JWT with JWE. "

I think you want to be stronger by saying that JWE MUST be used
when the authorization server wants to apply confidentiality
protection of the JWT. While the authorization server could use
other techniques as well the purpose of the document is to describe
one way to accomplish the goal and therefore it makes sense to be
specific.

I would even go as far as suggesting specific algorithms to use, as
an example.

* Although not stated directly I believe you allow the client
identifier to be created by a party other than the authorization
server. While this would theoretically make sense wouldn't it be
useful to just assume that the issuer is the authorization server?

Ciao Hannes _______________________________________________ OAuth
mailing list OAuth@ietf= .org
h= ttps://www.ietf.org/mailman/listinfo/oauth

 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

--_000_4c6d0f3169bd440995e511280b4b34a3BY2PR03MB189namprd03pro_-- From ve7jtb@ve7jtb.com Mon Nov 4 14:06:18 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07DD21E817A for ; Mon, 4 Nov 2013 14:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfUi3C5ko7DE for ; Mon, 4 Nov 2013 14:06:14 -0800 (PST) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9F321E81CD for ; Mon, 4 Nov 2013 14:05:42 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id xb4so7667968pbc.22 for ; Mon, 04 Nov 2013 14:05:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=j8Eil0quEXhpmOV8wQP96Cpw6HbyaCBwrkezBk+3JSA=; b=hUDgCpLZfTqtVSvXcqqm//H4i93RyT8BjxkNW97whO7x8V/KOBQSSSIXREVEHxt5j4 bSIqQF11Vt57xfNL4iQDh6jSdod3ms4Vs5nGQ/nJpdqeBUTD4oUckRn9boyBRRMgJXRp yqp/ABSpFNwYr7Y3MobT4JTVglpNmVKC/snGe7BTECJVK3s9f/dRoFGIPb4p5EDImhZ8 vt3hhPtDdMskyE0pNbchG9ptHTll3EvM/j/XSDvqzMLy6kTZijXDlGaqoOBAUQ7KuRK2 pU/X3oYGKToFy/DrF19Pkip3oV7/mWiyCHlIve6YqmzEr/eWWtAinQNmUiPLaMwJNqeZ edKg== X-Gm-Message-State: ALoCoQnEZ62SvenR7Bqi+lsSLHGZxzzn/sJFECbT/ofWMMDJUew4kwP5X79jC3N39+t8T+Az2uj0 X-Received: by 10.68.252.68 with SMTP id zq4mr4484038pbc.154.1383602742098; Mon, 04 Nov 2013 14:05:42 -0800 (PST) Received: from [192.168.6.17] (199-91-80-194.ip.van.radiant.net. [199.91.80.194]) by mx.google.com with ESMTPSA id sd3sm30248792pbb.42.2013.11.04.14.05.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 14:05:40 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_4D590395-7532-4637-B4A6-DE41FF4E724B"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: John Bradley In-Reply-To: <80c826af712c48a3bbb731861d2ca9cc@BY2PR03MB189.namprd03.prod.outlook.com> Date: Mon, 4 Nov 2013 14:05:28 -0800 Message-Id: <10FAF55F-945B-48F1-BF30-BB0D1D85BC30@ve7jtb.com> References: <5273E5AD.7010408@gmx.net> <3F75FA0B-CAC3-439A-866B-CFE116FADA4E@ve7jtb.com> <5273F7A2.70409@gmx.net> <80c826af712c48a3bbb731861d2ca9cc@BY2PR03MB189.namprd03.prod.outlook.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1816) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:06:18 -0000 --Apple-Mail=_4D590395-7532-4637-B4A6-DE41FF4E724B Content-Type: multipart/alternative; boundary="Apple-Mail=_7E0226AD-D2C6-482B-B02C-D9FE7BC92C62" --Apple-Mail=_7E0226AD-D2C6-482B-B02C-D9FE7BC92C62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The method the AS uses to identify the client is within the scope of the = WG. We have several drafts that relate to that topic of extending that = mechanism.=20 What we are discussing is how best to do that securely without requiring = the AS to issue and maintain per client passwords. John B. On Nov 4, 2013, at 1:48 PM, Anthony Nadalin = wrote: > We need to avoid encoding secrets and authentication with client_id as = authentication is not part of our mission > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Nat Sakimura > Sent: Monday, November 4, 2013 1:38 PM > To: Hannes Tschofenig > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 > =20 > Since the client_id is supposed to be opaque, it would probably be = better to JWE encrypt (note: all JWE encryption are integrity protected = as well) by the authorization server upon issuing it to the client. This = way, we have exactly one way of doing the things, and it works for both = symmetric and asymmetric case.=20 > =20 > I see this more useful in the case of symmetric client secret.=20 > =20 > If the client were just using public key crypto to authenticate itself = to the server, using the URI of the location of the client metadata as = the client_id would suffice.=20 > =20 > This has an advantage of smaller client_id.=20 > =20 >=20 > 2013/11/2 Hannes Tschofenig > Hi John, >=20 > thanks for the super-quick response. >=20 >=20 > Am 01.11.13 19:18, schrieb John Bradley: > =20 > The client_id would continue to be opaque to the client as it is now. > The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and > provide integrity if it is using a symmetric key (probably the > simplest thing if we are talking about a single registration endpoint > paired with a single AS) In more complicated scenarios where perhaps > a group of AS share a single registration endpoint you probably want > to use asymmetric signature then asymmetric encryption + integrity. > Those are deployment decisions that need to be documented but can be > transparent to teh client. > =20 > Maybe it would be good to state that in the document that this is a = possible option without introducing further complications (other than = the verification procedure is different). If the AS signs the JWT then = it just needs to compare whether the issuer field matches what it had = previously put in there. If someone else signs the JWT then it needs to = check with some trust anchor store or something similar whether it = trusts that specific issuer. >=20 >=20 >=20 >=20 > Sorry to my mind it is obvious that the JWT would be integrity > protected/signed for all clients including clients using asymmetric > authentication to the token endpoint, and and > signed+encrypted+integrity for clients using symmetric > authentication. That can be made clearer. > =20 > It would be good to say that because the effort is rather low and = there are benefits in doing so. > =20 >=20 >=20 > It might make sense to assume the issuer is just the AS but the AS > can do that without the benefit of a spec now, as there is no > interoperability issue. >=20 > The spec defining the JWT structure and signing and encryption > methods has the most benefit when you don't have such a tight > coupling between registration and AS. >=20 > That is likely why Justin and I didn't think a spec was necessary for > the simple case other than to show people this is possible with the > existing registration spec. > =20 > I think there is value in providing that information for implementers = even though it does not require new extensions or so. > =20 >=20 >=20 > I am OK with strengthening the wording on signing/integrity > protecting and encryption. eg if a symmetric key is included the JWT > MUST be encrypted. > =20 > Cool. > =20 >=20 > I don't necessarily want to make any algorithm a must as that limits > algorithm agility in the future. > OK. > =20 >=20 >=20 > Thanks for giving it a read, see you Sunday I expect. > Unfortunately not since I am unable to attend the upcoming IETF = meeting. Derek will run the show. >=20 > Ciao > Hannes > =20 >=20 >=20 > John B. >=20 >=20 > On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig > wrote: >=20 > Hi John, Hi all, >=20 > I read your document and here a few remarks. >=20 > In the dynamic client registration conference calls the topic of > the stateless client was raised since there was the argument in the > air that the current OAuth 2.0 RFC requires clients to be stateless > due to the nature of the client identifier. >=20 > It seems that you have found a way to make the client stateless > with regard to the client identifier (i.e., that the authorization > server does not need to store information about the client) by > dumping state information in the client identifier itself. In your > case you use a JWT, which is clever. >=20 > Since RFC 6749 explicitly says that the client identifier string > size is left undefined and that the client should avoid making > assumptions about the identifier size I don't see a problem with > the proposed approach. >=20 > Now, there is one issue that I am wondering about. The client > identifier itself is not sufficient for authorizing the client (for > confidential clients). Instead, there is typically the need to have > a secret. Now, the secret is not conveyed in the JWT, at least not > in the way you have define it. You could of course do that and > there is a document that provides prior art, see > http://www.ietf.org/rfc/rfc5077 The story essentially is that the > structure (JWT in your case) includes the key but of course then > you have to encrypt the entire blob. >=20 > In the case of public clients wouldn't you want to mandate at least > a digital signature or a keyed message digest for the JWT since > otherwise there is the risk that the client changes some of the > parameters to impersonate someone? >=20 > A few other questions: >=20 > * You write: "The issuer SHOULD sign the JWT with JWS in such a way > that the signature can be verified by the authorization server. " >=20 > I believe what you want to say is the following: The authorization > creates the client identifier (using the JWT) and the client does > not parse the received content since it treats it as opaque. > However, the authorization server MUST be able to process and > verify received client identifiers it previously created, which > requires to apply cryptographic processing when a JWT is signed > (using a JWS) and when a JWT is encrypted (using a JWE). >=20 > (I ignore the issue that I believe the JWT needs to be signed [for > public clients] and encrypted [for confidential clients].) >=20 > * You should submit the document as draft-bradley-oauth; this makes > it easier to find the document. >=20 > * You write: " The issuer MAY encrypt the JWT with JWE. " >=20 > I think you want to be stronger by saying that JWE MUST be used > when the authorization server wants to apply confidentiality > protection of the JWT. While the authorization server could use > other techniques as well the purpose of the document is to describe > one way to accomplish the goal and therefore it makes sense to be > specific. >=20 > I would even go as far as suggesting specific algorithms to use, as > an example. >=20 > * Although not stated directly I believe you allow the client > identifier to be created by a party other than the authorization > server. While this would theoretically make sense wouldn't it be > useful to just assume that the issuer is the authorization server? >=20 > Ciao Hannes _______________________________________________ OAuth > mailing list OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > =20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_7E0226AD-D2C6-482B-B02C-D9FE7BC92C62 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The = method the AS uses to identify the client is within the scope of the WG. =  We have several drafts that relate to that topic of extending that = mechanism. 

What we are discussing is how best = to do that securely without requiring the AS to issue and maintain per = client passwords.

John = B.


On Nov 4, 2013, at 1:48 PM, = Anthony Nadalin <tonynad@microsoft.com> = wrote:

We need to avoid encoding secrets and authentication = with client_id as authentication is not part of our = mission
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]<= span class=3D"Apple-converted-space"> On Behalf Of Nat = Sakimura
Sent: Monday, November 4, 2013 = 1:38 PM
To: Hannes = Tschofenig
Cc: oauth@ietf.org = WG
Subject: Re: [OAUTH-WG] = draft-bradley-stateless-oauth-client-00
 
Since the client_id is supposed to be opaque, it would probably = be better to JWE encrypt (note: all JWE encryption are integrity = protected as well) by the authorization server upon issuing it to the = client. This way, we have exactly one way of doing the things, and it = works for both symmetric and asymmetric = case. 
 
I see = this more useful in the case of symmetric client = secret. 
 
If = the client were just using public key crypto to authenticate itself to = the server, using the URI of the location of the client metadata as the = client_id would suffice. 
 
This has an advantage of smaller = client_id. 

 

2013/11/2 Hannes Tschofenig <hannes.tschofenig@gmx.net>
Hi = John,

thanks for the super-quick response.


Am 01.11.13 = 19:18, schrieb John Bradley:
 
The client_id would = continue to be opaque to the client as it is now.
The AS can send a = JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and
provide integrity = if it is using a symmetric key (probably the
simplest thing if we are = talking about a single registration endpoint
paired with a single AS) =  In more complicated scenarios where perhaps
a group of AS share = a single registration endpoint you probably want
to use asymmetric = signature  then asymmetric encryption + integrity.
Those are = deployment decisions that need to be documented but can = be
transparent to teh client.
 
Maybe it would be good to state that in the document that this = is a possible option without introducing further complications (other = than the verification procedure is different). If the AS signs the JWT = then it just needs to compare whether the issuer field matches what it = had previously put in there. If someone else signs the JWT then it needs = to check with some trust anchor store or something similar whether it = trusts that specific issuer.




Sorry to my mind it is = obvious that the JWT would be integrity
protected/signed for all = clients including clients using asymmetric
authentication to the = token endpoint, and and
signed+encrypted+integrity for clients using = symmetric
authentication.   That can be made = clearer.
 
It = would be good to say that because the effort is rather low and there are = benefits in doing so.

 


It might make sense to = assume the issuer is just the AS but the AS
can do that without the = benefit of a spec now, as there is no
interoperability = issue.

The spec defining the JWT structure and signing and = encryption
methods has the most benefit when you don't have such a = tight
coupling between registration and AS.

That is likely why = Justin and I didn't think a spec was necessary for
the simple case = other than to show people this is possible with the
existing = registration spec.
 
I = think there is value in providing that information for implementers even = though it does not require new extensions or so.

 


I = am OK with strengthening the wording on signing/integrity
protecting = and encryption.  eg if a symmetric key is included the JWT
MUST = be encrypted.
 
Cool.
 

I don't necessarily = want to make any algorithm a must as that limits
algorithm agility in = the future.
OK.

 


Thanks for giving it a = read, see you Sunday I expect.
Unfortunately not since I am unable to attend the = upcoming IETF meeting. Derek will run the show.

Ciao
Hannes

 


John B.


On Nov 1, 2013, at 2:32 PM, = Hannes Tschofenig
<hannes.tschofenig@gmx.net> = wrote:

Hi John, Hi all,

I read your document and = here a few remarks.

In the dynamic client registration conference = calls the topic of
the stateless client was raised since there was = the argument in the
air that the current OAuth 2.0 RFC requires = clients to be stateless
due to the nature of the client = identifier.

It seems that you have found a way to make the client = stateless
with regard to the client identifier (i.e., that the = authorization
server does not need to store information about the = client) by
dumping state information in the client identifier itself. = In your
case you use a JWT, which is clever.

Since RFC 6749 = explicitly says that the client identifier string
size is left = undefined  and that the client should avoid making
assumptions = about the identifier size I don't see a problem with
the proposed = approach.

Now, there is one issue that I am wondering about. The = client
identifier itself is not sufficient for authorizing the client = (for
confidential clients). Instead, there is typically the need to = have
a secret. Now, the secret is not conveyed in the JWT, at least = not
in the way you have define it. You could of course do that = and
there is a document that provides prior art, see
http://www.ietf.org/rfc/rfc5077 The story essentially is = that the
structure (JWT in your case) includes the key but of course = then
you have to encrypt the entire blob.

In the case of = public clients wouldn't you want to mandate at least
a digital = signature or a keyed message digest for the JWT since
otherwise there = is the risk that the client changes some of the
parameters to = impersonate someone?

A few other questions:

* You write: = "The issuer SHOULD sign the JWT with JWS in such a way
that the = signature can be verified by the authorization server. "

I = believe what you want to say is the following: The = authorization
creates the client identifier (using the JWT) and the = client does
not parse the received content since it treats it as = opaque.
However, the authorization server MUST be able to process = and
verify received client identifiers it previously created, = which
requires to apply cryptographic processing when a JWT is = signed
(using a JWS) and when a JWT is encrypted (using a = JWE).

(I ignore the issue that I believe the JWT needs to be = signed [for
public clients] and encrypted [for confidential = clients].)

* You should submit the document as = draft-bradley-oauth; this makes
it easier to find the = document.

* You write: " The issuer MAY encrypt the JWT with JWE. = "

I think you want to be stronger by saying that JWE MUST be = used
when the authorization server wants to apply = confidentiality
protection of the JWT. While the authorization server = could use
other techniques as well the purpose of the document is to = describe
one way to accomplish the goal and therefore it makes sense = to be
specific.

I would even go as far as suggesting specific = algorithms to use, as
an example.

* Although not stated = directly I believe you allow the client
identifier to be created by a = party other than the authorization
server. While this would = theoretically make sense wouldn't it be
useful to just assume that = the issuer is the authorization server?

Ciao Hannes = _______________________________________________ OAuth
mailing = list OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 

_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


 
-- 
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_7E0226AD-D2C6-482B-B02C-D9FE7BC92C62-- --Apple-Mail=_4D590395-7532-4637-B4A6-DE41FF4E724B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMTA0MjIwNTI4WjAjBgkqhkiG9w0BCQQxFgQUrZuUxwvo FnFQRWEy/eWL1aZddMMwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAl/xmCoRmLosCmco9OhqYRhUSABPSfWvUbInY8yTK pIk05uOicpzRE6UeC0DDpR8zkTDnMKDUXTFi3PdNdgj8+tL/v7Q2wWiTmGon+hLx7Dr02F4qMpV5 fmNssOUohSWrfWadiBvZtOrMEdFBu+2jccLBGDmtOgyPDfOBBTvqVmag8da2MXae2gAm65g83l08 dKpXCzm4DfgZ2ccum9uhA14b3gundn3n3iCReKiLHZKMcKFMjHB87e5SG0fbecwjrCcl+1c9mqCC nD9bSmgf7CMiOjPPWiLMCIZaT6vUt6LiMJGFVXkFRENfBni9QUk1SGSNXK4KuYutv9l/TgQLCwAA AAAAAA== --Apple-Mail=_4D590395-7532-4637-B4A6-DE41FF4E724B-- From phil.hunt@oracle.com Mon Nov 4 14:06:45 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA4F21E817A for ; Mon, 4 Nov 2013 14:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.424 X-Spam-Level: X-Spam-Status: No, score=-5.424 tagged_above=-999 required=5 tests=[AWL=-0.493, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFhiFOMiMH-X for ; Mon, 4 Nov 2013 14:06:40 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 558AA21E81BB for ; Mon, 4 Nov 2013 14:06:09 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA4M66oK026740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Nov 2013 22:06:07 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA4M65cQ000983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Nov 2013 22:06:06 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA4M65s5000958; Mon, 4 Nov 2013 22:06:05 GMT Received: from dhcp-a540.meeting.ietf.org (/31.133.165.64) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Nov 2013 14:06:04 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_CD220894-C1E2-4CB6-872F-7CB9B2F1989D" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: Date: Mon, 4 Nov 2013 14:06:01 -0800 Message-Id: <4F8C451C-FD59-43DC-B2F4-65EA2FF52DDC@oracle.com> References: <5273E5AD.7010408@gmx.net> <3F75FA0B-CAC3-439A-866B-CFE116FADA4E@ve7jtb.com> <5273F7A2.70409@gmx.net> To: Nat Sakimura X-Mailer: Apple Mail (2.1510) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:06:45 -0000 --Apple-Mail=_CD220894-C1E2-4CB6-872F-7CB9B2F1989D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 So how is a stateless client able to do the authorize flow? How does = the server know about the redirect_url? Is it wide open? Still would like to hear more about this. Sometimes attacking the = problem from a different direction leads to an innovative conclusion. Still I share the concerns of Tony and binding authentication into = client_id. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-11-04, at 1:58 PM, Nat Sakimura wrote: > I was assuming that the AS uses symmetric encryption as it is faster = and it just needs to be encrypted and decoded by itself.=20 >=20 >=20 > 2013/11/5 John Bradley > If the AS is using asymmetric encryption you need to both sign and = then encrypt as anyone can encrypt.=20 >=20 > Yes if the client has a TLS cert you could use a jwk_uri to keep the = size down. >=20 > John B. >=20 > On Nov 4, 2013, at 1:37 PM, Nat Sakimura wrote: >=20 >> Since the client_id is supposed to be opaque, it would probably be = better to JWE encrypt (note: all JWE encryption are integrity protected = as well) by the authorization server upon issuing it to the client. This = way, we have exactly one way of doing the things, and it works for both = symmetric and asymmetric case.=20 >>=20 >> I see this more useful in the case of symmetric client secret.=20 >>=20 >> If the client were just using public key crypto to authenticate = itself to the server, using the URI of the location of the client = metadata as the client_id would suffice.=20 >>=20 >> This has an advantage of smaller client_id.=20 >>=20 >>=20 >> 2013/11/2 Hannes Tschofenig >> Hi John, >>=20 >> thanks for the super-quick response. >>=20 >>=20 >> Am 01.11.13 19:18, schrieb John Bradley: >>=20 >> The client_id would continue to be opaque to the client as it is now. >> The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and >> provide integrity if it is using a symmetric key (probably the >> simplest thing if we are talking about a single registration endpoint >> paired with a single AS) In more complicated scenarios where perhaps >> a group of AS share a single registration endpoint you probably want >> to use asymmetric signature then asymmetric encryption + integrity. >> Those are deployment decisions that need to be documented but can be >> transparent to teh client. >>=20 >> Maybe it would be good to state that in the document that this is a = possible option without introducing further complications (other than = the verification procedure is different). If the AS signs the JWT then = it just needs to compare whether the issuer field matches what it had = previously put in there. If someone else signs the JWT then it needs to = check with some trust anchor store or something similar whether it = trusts that specific issuer. >>=20 >>=20 >>=20 >>=20 >> Sorry to my mind it is obvious that the JWT would be integrity >> protected/signed for all clients including clients using asymmetric >> authentication to the token endpoint, and and >> signed+encrypted+integrity for clients using symmetric >> authentication. That can be made clearer. >>=20 >> It would be good to say that because the effort is rather low and = there are benefits in doing so. >>=20 >>=20 >>=20 >> It might make sense to assume the issuer is just the AS but the AS >> can do that without the benefit of a spec now, as there is no >> interoperability issue. >>=20 >> The spec defining the JWT structure and signing and encryption >> methods has the most benefit when you don't have such a tight >> coupling between registration and AS. >>=20 >> That is likely why Justin and I didn't think a spec was necessary for >> the simple case other than to show people this is possible with the >> existing registration spec. >>=20 >> I think there is value in providing that information for implementers = even though it does not require new extensions or so. >>=20 >>=20 >>=20 >> I am OK with strengthening the wording on signing/integrity >> protecting and encryption. eg if a symmetric key is included the JWT >> MUST be encrypted. >>=20 >> Cool. >>=20 >>=20 >> I don't necessarily want to make any algorithm a must as that limits >> algorithm agility in the future. >> OK. >>=20 >>=20 >>=20 >> Thanks for giving it a read, see you Sunday I expect. >> Unfortunately not since I am unable to attend the upcoming IETF = meeting. Derek will run the show. >>=20 >> Ciao >> Hannes >>=20 >>=20 >>=20 >> John B. >>=20 >>=20 >> On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig >> wrote: >>=20 >> Hi John, Hi all, >>=20 >> I read your document and here a few remarks. >>=20 >> In the dynamic client registration conference calls the topic of >> the stateless client was raised since there was the argument in the >> air that the current OAuth 2.0 RFC requires clients to be stateless >> due to the nature of the client identifier. >>=20 >> It seems that you have found a way to make the client stateless >> with regard to the client identifier (i.e., that the authorization >> server does not need to store information about the client) by >> dumping state information in the client identifier itself. In your >> case you use a JWT, which is clever. >>=20 >> Since RFC 6749 explicitly says that the client identifier string >> size is left undefined and that the client should avoid making >> assumptions about the identifier size I don't see a problem with >> the proposed approach. >>=20 >> Now, there is one issue that I am wondering about. The client >> identifier itself is not sufficient for authorizing the client (for >> confidential clients). Instead, there is typically the need to have >> a secret. Now, the secret is not conveyed in the JWT, at least not >> in the way you have define it. You could of course do that and >> there is a document that provides prior art, see >> http://www.ietf.org/rfc/rfc5077 The story essentially is that the >> structure (JWT in your case) includes the key but of course then >> you have to encrypt the entire blob. >>=20 >> In the case of public clients wouldn't you want to mandate at least >> a digital signature or a keyed message digest for the JWT since >> otherwise there is the risk that the client changes some of the >> parameters to impersonate someone? >>=20 >> A few other questions: >>=20 >> * You write: "The issuer SHOULD sign the JWT with JWS in such a way >> that the signature can be verified by the authorization server. " >>=20 >> I believe what you want to say is the following: The authorization >> creates the client identifier (using the JWT) and the client does >> not parse the received content since it treats it as opaque. >> However, the authorization server MUST be able to process and >> verify received client identifiers it previously created, which >> requires to apply cryptographic processing when a JWT is signed >> (using a JWS) and when a JWT is encrypted (using a JWE). >>=20 >> (I ignore the issue that I believe the JWT needs to be signed [for >> public clients] and encrypted [for confidential clients].) >>=20 >> * You should submit the document as draft-bradley-oauth; this makes >> it easier to find the document. >>=20 >> * You write: " The issuer MAY encrypt the JWT with JWE. " >>=20 >> I think you want to be stronger by saying that JWE MUST be used >> when the authorization server wants to apply confidentiality >> protection of the JWT. While the authorization server could use >> other techniques as well the purpose of the document is to describe >> one way to accomplish the goal and therefore it makes sense to be >> specific. >>=20 >> I would even go as far as suggesting specific algorithms to use, as >> an example. >>=20 >> * Although not stated directly I believe you allow the client >> identifier to be created by a party other than the authorization >> server. While this would theoretically make sense wouldn't it be >> useful to just assume that the issuer is the authorization server? >>=20 >> Ciao Hannes _______________________________________________ OAuth >> mailing list OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_CD220894-C1E2-4CB6-872F-7CB9B2F1989D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 So = how is a stateless client able to do the authorize flow?  How does = the server know about the redirect_url?  Is it wide = open?

Still would like to hear more about this. =  Sometimes attacking the problem from a different direction leads = to an innovative conclusion.

Still I share the = concerns of Tony and binding authentication into = client_id.

On 2013-11-04, at 1:58 PM, Nat Sakimura <sakimura@gmail.com> = wrote:

I was assuming that the AS uses symmetric = encryption as it is faster and it just needs to be encrypted and decoded = by itself. 


2013/11/5 John Bradley <ve7jtb@ve7jtb.com>
If the AS is using asymmetric encryption = you need to both sign and then encrypt as anyone can encrypt. 

Yes if the client has a TLS cert you could use a jwk_uri = to keep the size down.

John = B.

On Nov 4, 2013, at 1:37 PM, = Nat Sakimura <sakimura@gmail.com> wrote:

Since the client_id is supposed to be opaque, it would = probably be better to JWE encrypt (note: all JWE encryption are = integrity protected as well) by the authorization server upon issuing it = to the client. This way, we have exactly one way of doing the things, = and it works for both symmetric and asymmetric case. 

I see this more useful in the case of symmetric client = secret. 

If the client were just using = public key crypto to authenticate itself to the server, using the URI of = the location of the client metadata as the client_id would = suffice. 

This has an advantage of smaller = client_id. 


2013/11/2 Hannes Tschofenig <hannes.tschofenig@gmx.net>
Hi John,

thanks for the super-quick response.


Am 01.11.13 19:18, schrieb John Bradley:

The client_id would continue to be opaque to the client as it is = now.
The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and
provide integrity if it is using a symmetric key (probably the
simplest thing if we are talking about a single registration = endpoint
paired with a single AS)  In more complicated scenarios where = perhaps
a group of AS share a single registration endpoint you probably want
to use asymmetric signature  then asymmetric encryption + = integrity.
Those are deployment decisions that need to be documented but can be
transparent to teh client.

Maybe it would be good to state that in the document that this is a = possible option without introducing further complications (other than = the verification procedure is different). If the AS signs the JWT then = it just needs to compare whether the issuer field matches what it had = previously put in there. If someone else signs the JWT then it needs to = check with some trust anchor store or something similar whether it = trusts that specific issuer.




Sorry to my mind it is obvious that the JWT would be integrity
protected/signed for all clients including clients using asymmetric
authentication to the token endpoint, and and
signed+encrypted+integrity for clients using symmetric
authentication.   That can be made clearer.

It would be good to say that because the effort is rather low and there = are benefits in doing so.



It might make sense to assume the issuer is just the AS but the AS
can do that without the benefit of a spec now, as there is no
interoperability issue.

The spec defining the JWT structure and signing and encryption
methods has the most benefit when you don't have such a tight
coupling between registration and AS.

That is likely why Justin and I didn't think a spec was necessary = for
the simple case other than to show people this is possible with the
existing registration spec.

I think there is value in providing that information for implementers = even though it does not require new extensions or so.



I am OK with strengthening the wording on signing/integrity
protecting and encryption.  eg if a symmetric key is included the = JWT
MUST be encrypted.

Cool.


I don't necessarily want to make any algorithm a must as that limits
algorithm agility in the future.
OK.



Thanks for giving it a read, see you Sunday I expect.
Unfortunately not since I am unable to attend the upcoming IETF meeting. = Derek will run the show.

Ciao
Hannes



John B.


On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig
<hannes.tschofenig@gmx.net> wrote:

Hi John, Hi all,

I read your document and here a few remarks.

In the dynamic client registration conference calls the topic of
the stateless client was raised since there was the argument in the
air that the current OAuth 2.0 RFC requires clients to be stateless
due to the nature of the client identifier.

It seems that you have found a way to make the client stateless
with regard to the client identifier (i.e., that the authorization
server does not need to store information about the client) by
dumping state information in the client identifier itself. In your
case you use a JWT, which is clever.

Since RFC 6749 explicitly says that the client identifier string
size is left undefined  and that the client should avoid making
assumptions about the identifier size I don't see a problem with
the proposed approach.

Now, there is one issue that I am wondering about. The client
identifier itself is not sufficient for authorizing the client (for
confidential clients). Instead, there is typically the need to have
a secret. Now, the secret is not conveyed in the JWT, at least not
in the way you have define it. You could of course do that and
there is a document that provides prior art, see
http://www.ietf.org/rfc/rfc5077 The story = essentially is that the
structure (JWT in your case) includes the key but of course then
you have to encrypt the entire blob.

In the case of public clients wouldn't you want to mandate at least
a digital signature or a keyed message digest for the JWT since
otherwise there is the risk that the client changes some of the
parameters to impersonate someone?

A few other questions:

* You write: "The issuer SHOULD sign the JWT with JWS in such a way
that the signature can be verified by the authorization server. "

I believe what you want to say is the following: The authorization
creates the client identifier (using the JWT) and the client does
not parse the received content since it treats it as opaque.
However, the authorization server MUST be able to process and
verify received client identifiers it previously created, which
requires to apply cryptographic processing when a JWT is signed
(using a JWS) and when a JWT is encrypted (using a JWE).

(I ignore the issue that I believe the JWT needs to be signed [for
public clients] and encrypted [for confidential clients].)

* You should submit the document as draft-bradley-oauth; this makes
it easier to find the document.

* You write: " The issuer MAY encrypt the JWT with JWE. "

I think you want to be stronger by saying that JWE MUST be used
when the authorization server wants to apply confidentiality
protection of the JWT. While the authorization server could use
other techniques as well the purpose of the document is to describe
one way to accomplish the goal and therefore it makes sense to be
specific.

I would even go as far as suggesting specific algorithms to use, as
an example.

* Although not stated directly I believe you allow the client
identifier to be created by a party other than the authorization
server. While this would theoretically make sense wouldn't it be
useful to just assume that the issuer is the authorization server?

Ciao Hannes _______________________________________________ = OAuth
mailing list OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
= https://www.ietf.org/mailman/listinfo/oauth



--
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
=




--
Nat Sakimura (=3Dnat)
Chairman, = OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_CD220894-C1E2-4CB6-872F-7CB9B2F1989D-- From tonynad@microsoft.com Mon Nov 4 14:10:42 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0B711E81E3 for ; Mon, 4 Nov 2013 14:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfJRMPYJU5lo for ; Mon, 4 Nov 2013 14:10:38 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id AF33E21F99BD for ; Mon, 4 Nov 2013 14:10:27 -0800 (PST) Received: from BY2PR03MB189.namprd03.prod.outlook.com (10.242.36.140) by BY2PR03MB190.namprd03.prod.outlook.com (10.242.36.141) with Microsoft SMTP Server (TLS) id 15.0.800.7; Mon, 4 Nov 2013 22:10:24 +0000 Received: from BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.32]) by BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.32]) with mapi id 15.00.0800.005; Mon, 4 Nov 2013 22:10:24 +0000 From: Anthony Nadalin To: John Bradley Thread-Topic: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 Thread-Index: AQHO1yhhDDhIjG7WR0uaCpkJVcwnaJoQrxMAgAAIsQCABOYfgIAAAliwgAAFZACAAADGIA== Date: Mon, 4 Nov 2013 22:10:24 +0000 Message-ID: References: <5273E5AD.7010408@gmx.net> <3F75FA0B-CAC3-439A-866B-CFE116FADA4E@ve7jtb.com> <5273F7A2.70409@gmx.net> <80c826af712c48a3bbb731861d2ca9cc@BY2PR03MB189.namprd03.prod.outlook.com> <10FAF55F-945B-48F1-BF30-BB0D1D85BC30@ve7jtb.com> In-Reply-To: <10FAF55F-945B-48F1-BF30-BB0D1D85BC30@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:160:3187:6e2b:e75:ce54] x-forefront-prvs: 0020414413 x-forefront-antispam-report: SFV:NSPM; SFS:(53754006)(199002)(189002)(24454002)(51914003)(479174003)(377454003)(52604005)(56776001)(4396001)(77982001)(49866001)(59766001)(47736001)(19300405004)(76482001)(16236675002)(15975445006)(31966008)(47446002)(74662001)(74502001)(74316001)(50986001)(47976001)(81686001)(33646001)(54316002)(83072001)(76796001)(76576001)(76786001)(53806001)(2656002)(19580405001)(81542001)(80022001)(19580395003)(54356001)(83322001)(85306002)(80976001)(51856001)(65816001)(46102001)(77096001)(56816003)(69226001)(79102001)(551544002)(81816001)(15202345003)(63696002)(81342001)(74706001)(74366001)(87266001)(19609705001)(74876001)(42262001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB190; H:BY2PR03MB189.namprd03.prod.outlook.com; CLIP:2001:67c:370:160:3187:6e2b:e75:ce54; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_e7fee513571a426cb9e1efbc5f14f759BY2PR03MB189namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:10:42 -0000 --_000_e7fee513571a426cb9e1efbc5f14f759BY2PR03MB189namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Identification is fine as long as it remains opaque and not specific to any= format. Authentication remains out of scope From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Monday, November 4, 2013 2:05 PM To: Anthony Nadalin Cc: Nat Sakimura; Hannes Tschofenig; oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 The method the AS uses to identify the client is within the scope of the WG= . We have several drafts that relate to that topic of extending that mecha= nism. What we are discussing is how best to do that securely without requiring th= e AS to issue and maintain per client passwords. John B. On Nov 4, 2013, at 1:48 PM, Anthony Nadalin > wrote: We need to avoid encoding secrets and authentication with client_id as auth= entication is not part of our mission From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Nat Sakimura Sent: Monday, November 4, 2013 1:38 PM To: Hannes Tschofenig Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 Since the client_id is supposed to be opaque, it would probably be better t= o JWE encrypt (note: all JWE encryption are integrity protected as well) by= the authorization server upon issuing it to the client. This way, we have = exactly one way of doing the things, and it works for both symmetric and as= ymmetric case. I see this more useful in the case of symmetric client secret. If the client were just using public key crypto to authenticate itself to t= he server, using the URI of the location of the client metadata as the clie= nt_id would suffice. This has an advantage of smaller client_id. 2013/11/2 Hannes Tschofenig > Hi John, thanks for the super-quick response. Am 01.11.13 19:18, schrieb John Bradley: The client_id would continue to be opaque to the client as it is now. The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and provide integrity if it is using a symmetric key (probably the simplest thing if we are talking about a single registration endpoint paired with a single AS) In more complicated scenarios where perhaps a group of AS share a single registration endpoint you probably want to use asymmetric signature then asymmetric encryption + integrity. Those are deployment decisions that need to be documented but can be transparent to teh client. Maybe it would be good to state that in the document that this is a possibl= e option without introducing further complications (other than the verifica= tion procedure is different). If the AS signs the JWT then it just needs to= compare whether the issuer field matches what it had previously put in the= re. If someone else signs the JWT then it needs to check with some trust an= chor store or something similar whether it trusts that specific issuer. Sorry to my mind it is obvious that the JWT would be integrity protected/signed for all clients including clients using asymmetric authentication to the token endpoint, and and signed+encrypted+integrity for clients using symmetric authentication. That can be made clearer. It would be good to say that because the effort is rather low and there are= benefits in doing so. It might make sense to assume the issuer is just the AS but the AS can do that without the benefit of a spec now, as there is no interoperability issue. The spec defining the JWT structure and signing and encryption methods has the most benefit when you don't have such a tight coupling between registration and AS. That is likely why Justin and I didn't think a spec was necessary for the simple case other than to show people this is possible with the existing registration spec. I think there is value in providing that information for implementers even = though it does not require new extensions or so. I am OK with strengthening the wording on signing/integrity protecting and encryption. eg if a symmetric key is included the JWT MUST be encrypted. Cool. I don't necessarily want to make any algorithm a must as that limits algorithm agility in the future. OK. Thanks for giving it a read, see you Sunday I expect. Unfortunately not since I am unable to attend the upcoming IETF meeting. De= rek will run the show. Ciao Hannes John B. On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig > wrote: Hi John, Hi all, I read your document and here a few remarks. In the dynamic client registration conference calls the topic of the stateless client was raised since there was the argument in the air that the current OAuth 2.0 RFC requires clients to be stateless due to the nature of the client identifier. It seems that you have found a way to make the client stateless with regard to the client identifier (i.e., that the authorization server does not need to store information about the client) by dumping state information in the client identifier itself. In your case you use a JWT, which is clever. Since RFC 6749 explicitly says that the client identifier string size is left undefined and that the client should avoid making assumptions about the identifier size I don't see a problem with the proposed approach. Now, there is one issue that I am wondering about. The client identifier itself is not sufficient for authorizing the client (for confidential clients). Instead, there is typically the need to have a secret. Now, the secret is not conveyed in the JWT, at least not in the way you have define it. You could of course do that and there is a document that provides prior art, see http://www.ietf.org/rfc/rfc5077 The story essentially is that the structure (JWT in your case) includes the key but of course then you have to encrypt the entire blob. In the case of public clients wouldn't you want to mandate at least a digital signature or a keyed message digest for the JWT since otherwise there is the risk that the client changes some of the parameters to impersonate someone? A few other questions: * You write: "The issuer SHOULD sign the JWT with JWS in such a way that the signature can be verified by the authorization server. " I believe what you want to say is the following: The authorization creates the client identifier (using the JWT) and the client does not parse the received content since it treats it as opaque. However, the authorization server MUST be able to process and verify received client identifiers it previously created, which requires to apply cryptographic processing when a JWT is signed (using a JWS) and when a JWT is encrypted (using a JWE). (I ignore the issue that I believe the JWT needs to be signed [for public clients] and encrypted [for confidential clients].) * You should submit the document as draft-bradley-oauth; this makes it easier to find the document. * You write: " The issuer MAY encrypt the JWT with JWE. " I think you want to be stronger by saying that JWE MUST be used when the authorization server wants to apply confidentiality protection of the JWT. While the authorization server could use other techniques as well the purpose of the document is to describe one way to accomplish the goal and therefore it makes sense to be specific. I would even go as far as suggesting specific algorithms to use, as an example. * Although not stated directly I believe you allow the client identifier to be created by a party other than the authorization server. While this would theoretically make sense wouldn't it be useful to just assume that the issuer is the authorization server? Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_e7fee513571a426cb9e1efbc5f14f759BY2PR03MB189namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Identification is fine as= long as it remains opaque and not specific to any format. Authentication r= emains out of scope

 

From: John B= radley [mailto:ve7jtb@ve7jtb.com]
Sent: Monday, November 4, 2013 2:05 PM
To: Anthony Nadalin
Cc: Nat Sakimura; Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00=

 

The method the AS uses to identify the client is wit= hin the scope of the WG.  We have several drafts that relate to that t= opic of extending that mechanism. 

 

What we are discussing is how best to do that secure= ly without requiring the AS to issue and maintain per client passwords.

 

John B.

 

 

On Nov 4, 2013, at 1:48 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:



We need to avoid encoding= secrets and authentication with client_id as authentication is not part of= our mission

 <= /p>

 

Since the client_id is supposed to be opaque, it wou= ld probably be better to JWE encrypt (note: all JWE encryption are integrit= y protected as well) by the authorization server upon issuing it to the cli= ent. This way, we have exactly one way of doing the things, and it works for both symmetric and asymmetric ca= se. 

 

I see this more useful in the case of symmetric clie= nt secret. 

 

If the client were just using public key crypto to a= uthenticate itself to the server, using the URI of the location of the clie= nt metadata as the client_id would suffice. 

 

This has an advantage of smaller client_id. 

 

2013/11/2 Hannes Tschofenig <han= nes.tschofenig@gmx.net>

Hi John,

thanks for the super-quick response.


Am 01.11.13 19:18, schrieb John Bradley:

 

The client_id would continue to be opaque to the cli= ent as it is now.
The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and
provide integrity if it is using a symmetric key (probably the
simplest thing if we are talking about a single registration endpoint
paired with a single AS)  In more complicated scenarios where perhaps<= br> a group of AS share a single registration endpoint you probably want
to use asymmetric signature  then asymmetric encryption + integrit= y.
Those are deployment decisions that need to be documented but can be
transparent to teh client.

 

Maybe it would be good to state that in the document= that this is a possible option without introducing further complications (= other than the verification procedure is different). If the AS signs the JW= T then it just needs to compare whether the issuer field matches what it had previously put in there. If someone e= lse signs the JWT then it needs to check with some trust anchor store or so= mething similar whether it trusts that specific issuer.





Sorry to my mind it is obvious that the JWT would be integrity
protected/signed for all clients including clients using asymmetric
authentication to the token endpoint, and and
signed+encrypted+integrity for clients using symmetric
authentication.   That can be made clearer.

 

It would be good to say that because the effort is r= ather low and there are benefits in doing so.

 


It might make sense to assume the issuer is just the AS but the AS
can do that without the benefit of a spec now, as there is no
interoperability issue.

The spec defining the JWT structure and signing and encryption
methods has the most benefit when you don't have such a tight
coupling between registration and AS.

That is likely why Justin and I didn't think a spec was necessary for
the simple case other than to show people this is possible with the
existing registration spec.

 

I think there is value in providing that information= for implementers even though it does not require new extensions or so.

 


I am OK with strengthening the wording on signing/integrity
protecting and encryption.  eg if a symmetric key is included the JWT<= br> MUST be encrypted.

 

Cool.

 


I don't necessarily want to make any algorithm a must as that limits
algorithm agility in the future.

OK.

 


Thanks for giving it a read, see you Sunday I expect.

Unfortunately not since I am unable to attend the up= coming IETF meeting. Derek will run the show.

Ciao
Hannes

 


John B.


On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig
<hannes.tschofenig@gmx.net> wrote:

Hi John, Hi all,

I read your document and here a few remarks.

In the dynamic client registration conference calls the topic of
the stateless client was raised since there was the argument in the
air that the current OAuth 2.0 RFC requires clients to be stateless
due to the nature of the client identifier.

It seems that you have found a way to make the client stateless
with regard to the client identifier (i.e., that the authorization
server does not need to store information about the client) by
dumping state information in the client identifier itself. In your
case you use a JWT, which is clever.

Since RFC 6749 explicitly says that the client identifier string
size is left undefined  and that the client should avoid making
assumptions about the identifier size I don't see a problem with
the proposed approach.

Now, there is one issue that I am wondering about. The client
identifier itself is not sufficient for authorizing the client (for
confidential clients). Instead, there is typically the need to have
a secret. Now, the secret is not conveyed in the JWT, at least not
in the way you have define it. You could of course do that and
there is a document that provides prior art, see
http://www.ietf.org/rfc/rfc5077 The story essentially is that the
structure (JWT in your case) includes the key but of course then
you have to encrypt the entire blob.

In the case of public clients wouldn't you want to mandate at least
a digital signature or a keyed message digest for the JWT since
otherwise there is the risk that the client changes some of the
parameters to impersonate someone?

A few other questions:

* You write: "The issuer SHOULD sign the JWT with JWS in such a way that the signature can be verified by the authorization server. "

I believe what you want to say is the following: The authorization
creates the client identifier (using the JWT) and the client does
not parse the received content since it treats it as opaque.
However, the authorization server MUST be able to process and
verify received client identifiers it previously created, which
requires to apply cryptographic processing when a JWT is signed
(using a JWS) and when a JWT is encrypted (using a JWE).

(I ignore the issue that I believe the JWT needs to be signed [for
public clients] and encrypted [for confidential clients].)

* You should submit the document as draft-bradley-oauth; this makes
it easier to find the document.

* You write: " The issuer MAY encrypt the JWT with JWE. "

I think you want to be stronger by saying that JWE MUST be used
when the authorization server wants to apply confidentiality
protection of the JWT. While the authorization server could use
other techniques as well the purpose of the document is to describe
one way to accomplish the goal and therefore it makes sense to be
specific.

I would even go as far as suggesting specific algorithms to use, as
an example.

* Although not stated directly I believe you allow the client
identifier to be created by a party other than the authorization
server. While this would theoretically make sense wouldn't it be
useful to just assume that the issuer is the authorization server?

Ciao Hannes _______________________________________________ OAuth
mailing list OAuth@= ietf.org
<= span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/oauth

 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
<= span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/oauth



 

-- 
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

______________________________________= _________
OAuth mailing list
OAuth@ietf.o= rg
https://www.ietf.org/mailman/listinfo/oauth=

 

--_000_e7fee513571a426cb9e1efbc5f14f759BY2PR03MB189namprd03pro_-- From Michael.Jones@microsoft.com Mon Nov 4 14:14:58 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83F921E827A for ; Mon, 4 Nov 2013 14:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bx5DuP1XjeUs for ; Mon, 4 Nov 2013 14:14:53 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0157.outbound.protection.outlook.com [207.46.163.157]) by ietfa.amsl.com (Postfix) with ESMTP id 83B3221F9D39 for ; Mon, 4 Nov 2013 14:14:05 -0800 (PST) Received: from BY2PR03CA028.namprd03.prod.outlook.com (10.242.234.149) by BY2PR03MB112.namprd03.prod.outlook.com (10.242.36.26) with Microsoft SMTP Server (TLS) id 15.0.815.6; Mon, 4 Nov 2013 22:14:03 +0000 Received: from BY2FFO11FD011.protection.gbl (2a01:111:f400:7c0c::108) by BY2PR03CA028.outlook.office365.com (2a01:111:e400:2c2c::21) with Microsoft SMTP Server (TLS) id 15.0.815.6 via Frontend Transport; Mon, 4 Nov 2013 22:14:03 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD011.mail.protection.outlook.com (10.1.14.129) with Microsoft SMTP Server (TLS) id 15.0.815.5 via Frontend Transport; Mon, 4 Nov 2013 22:14:03 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.160]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0158.002; Mon, 4 Nov 2013 22:13:15 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org WG" Thread-Topic: [OAUTH-WG] draft-ietf-oauth-json-web-token-12 Thread-Index: AQHO1zhaddbyc4KU+UWJrMJ6EdGL+5oVo/uA Date: Mon, 4 Nov 2013 22:13:14 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394377E3AF85@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <52740076.7050609@gmx.net> In-Reply-To: <52740076.7050609@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464003)(57704003)(377454003)(53754006)(199002)(189002)(80022001)(63696002)(20776003)(65816001)(66066001)(81542001)(56776001)(54316002)(50986001)(31966008)(51856001)(50466002)(77982001)(59766001)(74366001)(55846006)(74876001)(4396001)(2656002)(47976001)(49866001)(69226001)(54356001)(47736001)(81342001)(47446002)(46406003)(46102001)(53806001)(76786001)(76796001)(77096001)(56816003)(23726002)(83072001)(15975445006)(33656001)(81816001)(6806004)(83322001)(74706001)(87266001)(79102001)(15202345003)(74502001)(74662001)(47776003)(81686001)(19580405001)(19580395003)(80976001)(44976005)(76482001)(85306002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB112; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0020414413 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:14:59 -0000 -12 addresses a few of the review comments, but not the majority of them. = Those that it addresses are about "cty" and "typ". For instance, it does ad= dress Prateek's comment 2 (Why do we need both a "typ" claim and a "typ" he= ader name?) and James' comment 7 (The doc redefines the "cty" header parame= ter). (We no longer have both a "typ" claim and "typ" header parameter; "c= ty" is not redefined.) The reality is that lately more of my time has gone into addressing the num= erous JOSE comments, to try to get those documents that we depend upon to a= stable point, than addressing the relatively small number of JWT comments.= But I will try to respond to the four sets of WGLC comments received this= week, once my prep work for the JOSE meeting on Thursday is done. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Friday, November 01, 2013 12:27 PM To: oauth@ietf.org WG Subject: [OAUTH-WG] draft-ietf-oauth-json-web-token-12 Hi Mike, Hi all, I was just trying to find out whether version -12 of the JWT spec addresses= prior comments and the diff version of the document does not really give t= hat indication. To me it seems that version -12 of the document was publish= ed to update -11 in an attempt to create an alignment with the JOSE work. I believe it would be useful to respond to the review comments so that we c= an be sure that those had been taken into account (or that they had been re= jected for a good reason). Here are the comments I have found: * Review by James Manger: http://www.ietf.org/mail-archive/web/oauth/current/msg11905.html * Review by Mishra Prateek: http://www.ietf.org/mail-archive/web/oauth/current/msg12003.html * My own shepherd review: http://www.ietf.org/mail-archive/web/oauth/current/msg12125.html Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Mon Nov 4 14:17:54 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167F821E81BC for ; Mon, 4 Nov 2013 14:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.551 X-Spam-Level: X-Spam-Status: No, score=-5.551 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qohHsnzDEq0K for ; Mon, 4 Nov 2013 14:17:49 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9211E21E8225 for ; Mon, 4 Nov 2013 14:16:56 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0F9661F07D1; Mon, 4 Nov 2013 17:16:56 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id DE5C61F07D0; Mon, 4 Nov 2013 17:16:55 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.251]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0158.001; Mon, 4 Nov 2013 17:16:55 -0500 From: "Richer, Justin P." To: Phil Hunt Thread-Topic: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 Thread-Index: AQHO2aincgD9QrhhQUyWBFngL5p9IpoV8nAAgAACKICAAAMMgA== Date: Mon, 4 Nov 2013 22:16:54 +0000 Message-ID: References: <5273E5AD.7010408@gmx.net> <3F75FA0B-CAC3-439A-866B-CFE116FADA4E@ve7jtb.com> <5273F7A2.70409@gmx.net> <4F8C451C-FD59-43DC-B2F4-65EA2FF52DDC@oracle.com> In-Reply-To: <4F8C451C-FD59-43DC-B2F4-65EA2FF52DDC@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.39.63] Content-Type: multipart/alternative; boundary="_000_C35E0F8C6F984F2C847877CCC843F13Amitreorg_" MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:17:54 -0000 --_000_C35E0F8C6F984F2C847877CCC843F13Amitreorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The redirect URI is built into the structure of the client_id that the clie= nt passes that the AS can parse and check. Think of it as effectively using= a structure analogous the software statement as the client_id itself, whic= h you independently proposed as part of your client association draft's dis= cussion sections (for transient clients in your use case, stateless auth se= rvers in this use case). Authentication of the client is separate, the open question is how people w= ant to communicate the client's authentication credentials to the client in= a way that the AS can later recognize. Some people were getting hung up on= stuffing the client secret itself into the client_id, in which case you'd = need to encrypt the client_id's structure to hide the secret. There are ple= nty of alternatives though, including just not using client secrets for sta= teless auth servers (where they don't make as much sense anyway). -- Justin On Nov 4, 2013, at 2:06 PM, Phil Hunt > wrote: So how is a stateless client able to do the authorize flow? How does the s= erver know about the redirect_url? Is it wide open? Still would like to hear more about this. Sometimes attacking the problem = from a different direction leads to an innovative conclusion. Still I share the concerns of Tony and binding authentication into client_i= d. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-11-04, at 1:58 PM, Nat Sakimura > wrote: I was assuming that the AS uses symmetric encryption as it is faster and it= just needs to be encrypted and decoded by itself. 2013/11/5 John Bradley > If the AS is using asymmetric encryption you need to both sign and then enc= rypt as anyone can encrypt. Yes if the client has a TLS cert you could use a jwk_uri to keep the size d= own. John B. On Nov 4, 2013, at 1:37 PM, Nat Sakimura > wrote: Since the client_id is supposed to be opaque, it would probably be better t= o JWE encrypt (note: all JWE encryption are integrity protected as well) by= the authorization server upon issuing it to the client. This way, we have = exactly one way of doing the things, and it works for both symmetric and as= ymmetric case. I see this more useful in the case of symmetric client secret. If the client were just using public key crypto to authenticate itself to t= he server, using the URI of the location of the client metadata as the clie= nt_id would suffice. This has an advantage of smaller client_id. 2013/11/2 Hannes Tschofenig > Hi John, thanks for the super-quick response. Am 01.11.13 19:18, schrieb John Bradley: The client_id would continue to be opaque to the client as it is now. The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and provide integrity if it is using a symmetric key (probably the simplest thing if we are talking about a single registration endpoint paired with a single AS) In more complicated scenarios where perhaps a group of AS share a single registration endpoint you probably want to use asymmetric signature then asymmetric encryption + integrity. Those are deployment decisions that need to be documented but can be transparent to teh client. Maybe it would be good to state that in the document that this is a possibl= e option without introducing further complications (other than the verifica= tion procedure is different). If the AS signs the JWT then it just needs to= compare whether the issuer field matches what it had previously put in the= re. If someone else signs the JWT then it needs to check with some trust an= chor store or something similar whether it trusts that specific issuer. Sorry to my mind it is obvious that the JWT would be integrity protected/signed for all clients including clients using asymmetric authentication to the token endpoint, and and signed+encrypted+integrity for clients using symmetric authentication. That can be made clearer. It would be good to say that because the effort is rather low and there are= benefits in doing so. It might make sense to assume the issuer is just the AS but the AS can do that without the benefit of a spec now, as there is no interoperability issue. The spec defining the JWT structure and signing and encryption methods has the most benefit when you don't have such a tight coupling between registration and AS. That is likely why Justin and I didn't think a spec was necessary for the simple case other than to show people this is possible with the existing registration spec. I think there is value in providing that information for implementers even = though it does not require new extensions or so. I am OK with strengthening the wording on signing/integrity protecting and encryption. eg if a symmetric key is included the JWT MUST be encrypted. Cool. I don't necessarily want to make any algorithm a must as that limits algorithm agility in the future. OK. Thanks for giving it a read, see you Sunday I expect. Unfortunately not since I am unable to attend the upcoming IETF meeting. De= rek will run the show. Ciao Hannes John B. On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig > wrote: Hi John, Hi all, I read your document and here a few remarks. In the dynamic client registration conference calls the topic of the stateless client was raised since there was the argument in the air that the current OAuth 2.0 RFC requires clients to be stateless due to the nature of the client identifier. It seems that you have found a way to make the client stateless with regard to the client identifier (i.e., that the authorization server does not need to store information about the client) by dumping state information in the client identifier itself. In your case you use a JWT, which is clever. Since RFC 6749 explicitly says that the client identifier string size is left undefined and that the client should avoid making assumptions about the identifier size I don't see a problem with the proposed approach. Now, there is one issue that I am wondering about. The client identifier itself is not sufficient for authorizing the client (for confidential clients). Instead, there is typically the need to have a secret. Now, the secret is not conveyed in the JWT, at least not in the way you have define it. You could of course do that and there is a document that provides prior art, see http://www.ietf.org/rfc/rfc5077 The story essentially is that the structure (JWT in your case) includes the key but of course then you have to encrypt the entire blob. In the case of public clients wouldn't you want to mandate at least a digital signature or a keyed message digest for the JWT since otherwise there is the risk that the client changes some of the parameters to impersonate someone? A few other questions: * You write: "The issuer SHOULD sign the JWT with JWS in such a way that the signature can be verified by the authorization server. " I believe what you want to say is the following: The authorization creates the client identifier (using the JWT) and the client does not parse the received content since it treats it as opaque. However, the authorization server MUST be able to process and verify received client identifiers it previously created, which requires to apply cryptographic processing when a JWT is signed (using a JWS) and when a JWT is encrypted (using a JWE). (I ignore the issue that I believe the JWT needs to be signed [for public clients] and encrypted [for confidential clients].) * You should submit the document as draft-bradley-oauth; this makes it easier to find the document. * You write: " The issuer MAY encrypt the JWT with JWE. " I think you want to be stronger by saying that JWE MUST be used when the authorization server wants to apply confidentiality protection of the JWT. While the authorization server could use other techniques as well the purpose of the document is to describe one way to accomplish the goal and therefore it makes sense to be specific. I would even go as far as suggesting specific algorithms to use, as an example. * Although not stated directly I believe you allow the client identifier to be created by a party other than the authorization server. While this would theoretically make sense wouldn't it be useful to just assume that the issuer is the authorization server? Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C35E0F8C6F984F2C847877CCC843F13Amitreorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <0885495627683F4AA7DB2797513780D3@imc.mitre.org> Content-Transfer-Encoding: quoted-printable The redirect URI is built into the structure of the client_id that the clie= nt passes that the AS can parse and check. Think of it as effectively using= a structure analogous the software statement as the client_id itself,= which you independently proposed as part of your client association draft's discussion sections (for transient= clients in your use case, stateless auth servers in this use case). 

Authentication of the client is separate, the open question is how peo= ple want to communicate the client's authentication credentials to the clie= nt in a way that the AS can later recognize. Some people were getting hung = up on stuffing the client secret itself into the client_id, in which case you'd need to encrypt the client_= id's structure to hide the secret. There are plenty of alternatives though,= including just not using client secrets for stateless auth servers (where = they don't make as much sense anyway).

 -- Justin

On Nov 4, 2013, at 2:06 PM, Phil Hunt <phil.hunt@oracle.com>
 wrote:

So how is a stateless client able to do the authorize flow?  How does = the server know about the redirect_url?  Is it wide open?

Still would like to hear more about this.  Sometimes attacking th= e problem from a different direction leads to an innovative conclusion.

Still I share the concerns of Tony and binding authentication into cli= ent_id.

On 2013-11-04, at 1:58 PM, Nat Sakimura <sakimura@gmail.com> wrote:

I was assuming that the AS uses symmetric encryption as it= is faster and it just needs to be encrypted and decoded by itself. 


2013/11/5 John Bradley <ve7jtb@ve7jtb.com&g= t;
If the AS is using asymmetric encryptio= n you need to both sign and then encrypt as anyone can encrypt. 

Yes if the client has a TLS cert you could use a jwk_uri to keep the s= ize down.

John B.

On Nov 4, 2013, at 1:37 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Since the client_id is supposed to be opaque, it would pro= bably be better to JWE encrypt (note: all JWE encryption are integrity prot= ected as well) by the authorization server upon issuing it to the client. T= his way, we have exactly one way of doing the things, and it works for both symmetric and asymmetric case.&nbs= p;

I see this more useful in the case of symmetric client secret. 

If the client were just using public key crypto to authenticate itself= to the server, using the URI of the location of the client metadata as the= client_id would suffice. 

This has an advantage of smaller client_id. 


2013/11/2 Hannes Tschofenig &l= t;hannes.tsc= hofenig@gmx.net>
Hi John,

thanks for the super-quick response.


Am 01.11.13 19:18, schrieb John Bradley:

The client_id would continue to be opaque to the client as it is now.
The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and
provide integrity if it is using a symmetric key (probably the
simplest thing if we are talking about a single registration endpoint
paired with a single AS)  In more complicated scenarios where perhaps<= br> a group of AS share a single registration endpoint you probably want
to use asymmetric signature  then asymmetric encryption + integrit= y.
Those are deployment decisions that need to be documented but can be
transparent to teh client.

Maybe it would be good to state that in the document that this is a possibl= e option without introducing further complications (other than the verifica= tion procedure is different). If the AS signs the JWT then it just needs to= compare whether the issuer field matches what it had previously put in there. If someone else signs the JWT= then it needs to check with some trust anchor store or something similar w= hether it trusts that specific issuer.




Sorry to my mind it is obvious that the JWT would be integrity
protected/signed for all clients including clients using asymmetric
authentication to the token endpoint, and and
signed+encrypted+integrity for clients using symmetric
authentication.   That can be made clearer.

It would be good to say that because the effort is rather low and there are= benefits in doing so.



It might make sense to assume the issuer is just the AS but the AS
can do that without the benefit of a spec now, as there is no
interoperability issue.

The spec defining the JWT structure and signing and encryption
methods has the most benefit when you don't have such a tight
coupling between registration and AS.

That is likely why Justin and I didn't think a spec was necessary for
the simple case other than to show people this is possible with the
existing registration spec.

I think there is value in providing that information for implementers even = though it does not require new extensions or so.



I am OK with strengthening the wording on signing/integrity
protecting and encryption.  eg if a symmetric key is included the JWT<= br> MUST be encrypted.

Cool.


I don't necessarily want to make any algorithm a must as that limits
algorithm agility in the future.
OK.



Thanks for giving it a read, see you Sunday I expect.
Unfortunately not since I am unable to attend the upcoming IETF meeting. De= rek will run the show.

Ciao
Hannes



John B.


On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig
<hannes.t= schofenig@gmx.net> wrote:

Hi John, Hi all,

I read your document and here a few remarks.

In the dynamic client registration conference calls the topic of
the stateless client was raised since there was the argument in the
air that the current OAuth 2.0 RFC requires clients to be stateless
due to the nature of the client identifier.

It seems that you have found a way to make the client stateless
with regard to the client identifier (i.e., that the authorization
server does not need to store information about the client) by
dumping state information in the client identifier itself. In your
case you use a JWT, which is clever.

Since RFC 6749 explicitly says that the client identifier string
size is left undefined  and that the client should avoid making
assumptions about the identifier size I don't see a problem with
the proposed approach.

Now, there is one issue that I am wondering about. The client
identifier itself is not sufficient for authorizing the client (for
confidential clients). Instead, there is typically the need to have
a secret. Now, the secret is not conveyed in the JWT, at least not
in the way you have define it. You could of course do that and
there is a document that provides prior art, see
http://www.ie= tf.org/rfc/rfc5077 The story essentially is that the
structure (JWT in your case) includes the key but of course then
you have to encrypt the entire blob.

In the case of public clients wouldn't you want to mandate at least
a digital signature or a keyed message digest for the JWT since
otherwise there is the risk that the client changes some of the
parameters to impersonate someone?

A few other questions:

* You write: "The issuer SHOULD sign the JWT with JWS in such a way that the signature can be verified by the authorization server. "

I believe what you want to say is the following: The authorization
creates the client identifier (using the JWT) and the client does
not parse the received content since it treats it as opaque.
However, the authorization server MUST be able to process and
verify received client identifiers it previously created, which
requires to apply cryptographic processing when a JWT is signed
(using a JWS) and when a JWT is encrypted (using a JWE).

(I ignore the issue that I believe the JWT needs to be signed [for
public clients] and encrypted [for confidential clients].)

* You should submit the document as draft-bradley-oauth; this makes
it easier to find the document.

* You write: " The issuer MAY encrypt the JWT with JWE. "

I think you want to be stronger by saying that JWE MUST be used
when the authorization server wants to apply confidentiality
protection of the JWT. While the authorization server could use
other techniques as well the purpose of the document is to describe
one way to accomplish the goal and therefore it makes sense to be
specific.

I would even go as far as suggesting specific algorithms to use, as
an example.

* Although not stated directly I believe you allow the client
identifier to be created by a party other than the authorization
server. While this would theoretically make sense wouldn't it be
useful to just assume that the issuer is the authorization server?

Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf= .org
h= ttps://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--_000_C35E0F8C6F984F2C847877CCC843F13Amitreorg_-- From ve7jtb@ve7jtb.com Mon Nov 4 14:22:57 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2BF21F9E52 for ; Mon, 4 Nov 2013 14:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGYpRXyAncEu for ; Mon, 4 Nov 2013 14:22:53 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2A09911E81ED for ; Mon, 4 Nov 2013 14:22:51 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb1so7541513pad.17 for ; Mon, 04 Nov 2013 14:22:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=FmI/Dasvyco9Qvf25/Obu1lpGjEY5XEKDyDwI2N9L7k=; b=miiePq2lOBvxuR1N/eKH5Lcevj0nOkKbuEvwedzS5kFMGR3sGGjil19rw80QS4fzDB UYEM5Nq1wnilL8JFRgabQzVYPYZStSyOHZbmQOE1vgky/9ehAhbq/7EXP8s7+UdVFqrs km7TNUMfddM05B9+0vgcCn+XzX8cQbCR5axEw7IsWgf11cC2CBKZul3yaMdg7MezumnA azsRaMsMcXvNTFFCiA9Mj0ikFDtbyxpQVRHEsj6vhY0cvNWXYC46N5nqm03pxRBn1j0r Z8DbtierAWsDlhpWUyvYh55rkmNBx3uPUzyDQb0UtWd8JhH5f5fWwhF3BlZlkypkJDrs KI0A== X-Gm-Message-State: ALoCoQmbYkM7ohPRPwsm2frXYTZI5F4ccWuPL+r2ZgFRcmr3suzM22ofT2whMeLHfNA3Opwd8eSd X-Received: by 10.66.160.102 with SMTP id xj6mr5457781pab.72.1383603770159; Mon, 04 Nov 2013 14:22:50 -0800 (PST) Received: from [192.168.6.17] (199-91-80-194.ip.van.radiant.net. [199.91.80.194]) by mx.google.com with ESMTPSA id sg1sm30311809pbb.16.2013.11.04.14.22.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 14:22:49 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D591B4E6-0317-45C9-B7C4-321BCBE02AB3" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: John Bradley In-Reply-To: <4F8C451C-FD59-43DC-B2F4-65EA2FF52DDC@oracle.com> Date: Mon, 4 Nov 2013 14:22:31 -0800 Message-Id: <82A7937E-1A09-4655-977C-43F6C7C1D17F@ve7jtb.com> References: <5273E5AD.7010408@gmx.net> <3F75FA0B-CAC3-439A-866B-CFE116FADA4E@ve7jtb.com> <5273F7A2.70409@gmx.net> <4F8C451C-FD59-43DC-B2F4-65EA2FF52DDC@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1816) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:22:57 -0000 --Apple-Mail=_D591B4E6-0317-45C9-B7C4-321BCBE02AB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 If you read the draft the redirect URI and other parameters are encoded = into the JWT assertion.=20 What we are proposing is using an assertion/token as the client_id that = assertion cannot be a bearer assertion for confidential clients, that = would be inssecure. IT needs to be some sort of proof of possession assertion/token. There = are several ways to do proof of possession one is including a public key = and the other is encrypting a symmetric key. The option I didn't include is using some sort of key derivation = mechanism, DH etc so that you don't need to encrypt if using a symmetric = password. Symmetric passwords have all sorts of problems. A static assertion = without PoP has similar problems with securing it in the client. For reference the sort of compromises I am concerned about are already = starting to happen. = http://blog.programmableweb.com/2013/11/04/why-the-attack-on-buffer-was-a-= serious-wake-up-call-for-the-web/ John B. On Nov 4, 2013, at 2:06 PM, Phil Hunt wrote: > So how is a stateless client able to do the authorize flow? How does = the server know about the redirect_url? Is it wide open? >=20 > Still would like to hear more about this. Sometimes attacking the = problem from a different direction leads to an innovative conclusion. >=20 > Still I share the concerns of Tony and binding authentication into = client_id. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 > On 2013-11-04, at 1:58 PM, Nat Sakimura wrote: >=20 >> I was assuming that the AS uses symmetric encryption as it is faster = and it just needs to be encrypted and decoded by itself.=20 >>=20 >>=20 >> 2013/11/5 John Bradley >> If the AS is using asymmetric encryption you need to both sign and = then encrypt as anyone can encrypt.=20 >>=20 >> Yes if the client has a TLS cert you could use a jwk_uri to keep the = size down. >>=20 >> John B. >>=20 >> On Nov 4, 2013, at 1:37 PM, Nat Sakimura wrote: >>=20 >>> Since the client_id is supposed to be opaque, it would probably be = better to JWE encrypt (note: all JWE encryption are integrity protected = as well) by the authorization server upon issuing it to the client. This = way, we have exactly one way of doing the things, and it works for both = symmetric and asymmetric case.=20 >>>=20 >>> I see this more useful in the case of symmetric client secret.=20 >>>=20 >>> If the client were just using public key crypto to authenticate = itself to the server, using the URI of the location of the client = metadata as the client_id would suffice.=20 >>>=20 >>> This has an advantage of smaller client_id.=20 >>>=20 >>>=20 >>> 2013/11/2 Hannes Tschofenig >>> Hi John, >>>=20 >>> thanks for the super-quick response. >>>=20 >>>=20 >>> Am 01.11.13 19:18, schrieb John Bradley: >>>=20 >>> The client_id would continue to be opaque to the client as it is = now. >>> The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and >>> provide integrity if it is using a symmetric key (probably the >>> simplest thing if we are talking about a single registration = endpoint >>> paired with a single AS) In more complicated scenarios where = perhaps >>> a group of AS share a single registration endpoint you probably want >>> to use asymmetric signature then asymmetric encryption + integrity. >>> Those are deployment decisions that need to be documented but can be >>> transparent to teh client. >>>=20 >>> Maybe it would be good to state that in the document that this is a = possible option without introducing further complications (other than = the verification procedure is different). If the AS signs the JWT then = it just needs to compare whether the issuer field matches what it had = previously put in there. If someone else signs the JWT then it needs to = check with some trust anchor store or something similar whether it = trusts that specific issuer. >>>=20 >>>=20 >>>=20 >>>=20 >>> Sorry to my mind it is obvious that the JWT would be integrity >>> protected/signed for all clients including clients using asymmetric >>> authentication to the token endpoint, and and >>> signed+encrypted+integrity for clients using symmetric >>> authentication. That can be made clearer. >>>=20 >>> It would be good to say that because the effort is rather low and = there are benefits in doing so. >>>=20 >>>=20 >>>=20 >>> It might make sense to assume the issuer is just the AS but the AS >>> can do that without the benefit of a spec now, as there is no >>> interoperability issue. >>>=20 >>> The spec defining the JWT structure and signing and encryption >>> methods has the most benefit when you don't have such a tight >>> coupling between registration and AS. >>>=20 >>> That is likely why Justin and I didn't think a spec was necessary = for >>> the simple case other than to show people this is possible with the >>> existing registration spec. >>>=20 >>> I think there is value in providing that information for = implementers even though it does not require new extensions or so. >>>=20 >>>=20 >>>=20 >>> I am OK with strengthening the wording on signing/integrity >>> protecting and encryption. eg if a symmetric key is included the = JWT >>> MUST be encrypted. >>>=20 >>> Cool. >>>=20 >>>=20 >>> I don't necessarily want to make any algorithm a must as that limits >>> algorithm agility in the future. >>> OK. >>>=20 >>>=20 >>>=20 >>> Thanks for giving it a read, see you Sunday I expect. >>> Unfortunately not since I am unable to attend the upcoming IETF = meeting. Derek will run the show. >>>=20 >>> Ciao >>> Hannes >>>=20 >>>=20 >>>=20 >>> John B. >>>=20 >>>=20 >>> On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig >>> wrote: >>>=20 >>> Hi John, Hi all, >>>=20 >>> I read your document and here a few remarks. >>>=20 >>> In the dynamic client registration conference calls the topic of >>> the stateless client was raised since there was the argument in the >>> air that the current OAuth 2.0 RFC requires clients to be stateless >>> due to the nature of the client identifier. >>>=20 >>> It seems that you have found a way to make the client stateless >>> with regard to the client identifier (i.e., that the authorization >>> server does not need to store information about the client) by >>> dumping state information in the client identifier itself. In your >>> case you use a JWT, which is clever. >>>=20 >>> Since RFC 6749 explicitly says that the client identifier string >>> size is left undefined and that the client should avoid making >>> assumptions about the identifier size I don't see a problem with >>> the proposed approach. >>>=20 >>> Now, there is one issue that I am wondering about. The client >>> identifier itself is not sufficient for authorizing the client (for >>> confidential clients). Instead, there is typically the need to have >>> a secret. Now, the secret is not conveyed in the JWT, at least not >>> in the way you have define it. You could of course do that and >>> there is a document that provides prior art, see >>> http://www.ietf.org/rfc/rfc5077 The story essentially is that the >>> structure (JWT in your case) includes the key but of course then >>> you have to encrypt the entire blob. >>>=20 >>> In the case of public clients wouldn't you want to mandate at least >>> a digital signature or a keyed message digest for the JWT since >>> otherwise there is the risk that the client changes some of the >>> parameters to impersonate someone? >>>=20 >>> A few other questions: >>>=20 >>> * You write: "The issuer SHOULD sign the JWT with JWS in such a way >>> that the signature can be verified by the authorization server. " >>>=20 >>> I believe what you want to say is the following: The authorization >>> creates the client identifier (using the JWT) and the client does >>> not parse the received content since it treats it as opaque. >>> However, the authorization server MUST be able to process and >>> verify received client identifiers it previously created, which >>> requires to apply cryptographic processing when a JWT is signed >>> (using a JWS) and when a JWT is encrypted (using a JWE). >>>=20 >>> (I ignore the issue that I believe the JWT needs to be signed [for >>> public clients] and encrypted [for confidential clients].) >>>=20 >>> * You should submit the document as draft-bradley-oauth; this makes >>> it easier to find the document. >>>=20 >>> * You write: " The issuer MAY encrypt the JWT with JWE. " >>>=20 >>> I think you want to be stronger by saying that JWE MUST be used >>> when the authorization server wants to apply confidentiality >>> protection of the JWT. While the authorization server could use >>> other techniques as well the purpose of the document is to describe >>> one way to accomplish the goal and therefore it makes sense to be >>> specific. >>>=20 >>> I would even go as far as suggesting specific algorithms to use, as >>> an example. >>>=20 >>> * Although not stated directly I believe you allow the client >>> identifier to be created by a party other than the authorization >>> server. While this would theoretically make sense wouldn't it be >>> useful to just assume that the issuer is the authorization server? >>>=20 >>> Ciao Hannes _______________________________________________ OAuth >>> mailing list OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>> --=20 >>> Nat Sakimura (=3Dnat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>=20 >>=20 >>=20 >>=20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_D591B4E6-0317-45C9-B7C4-321BCBE02AB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 If you read the draft the = redirect URI and other parameters are encoded into the JWT = assertion. 

What we are proposing is using an = assertion/token as the client_id that assertion cannot be a bearer = assertion for confidential clients, that would be = inssecure.
IT needs to be some sort of proof of possession = assertion/token.   There are several ways to do proof of possession = one is including a public key and the other is encrypting a symmetric = key.

The option I didn't include is using some = sort of key derivation mechanism, DH etc so that you don't need to = encrypt if using a symmetric = password.

Symmetric passwords have all sorts of = problems.   A static assertion without PoP has similar problems = with securing it in the client.

For reference = the sort of compromises I am concerned about are already starting to = happen.

John = B.

On Nov 4, 2013, at 2:06 PM, Phil = Hunt <phil.hunt@oracle.com> = wrote:

So = how is a stateless client able to do the authorize flow?  How does = the server know about the redirect_url?  Is it wide = open?

Still would like to hear more about this. =  Sometimes attacking the problem from a different direction leads = to an innovative conclusion.

Still I share the = concerns of Tony and binding authentication into = client_id.
www.independentid.com
phil.hunt@oracle.com
=

On 2013-11-04, at 1:58 PM, Nat Sakimura <sakimura@gmail.com> = wrote:

I was assuming that the AS uses symmetric = encryption as it is faster and it just needs to be encrypted and decoded = by itself. 


2013/11/5 John Bradley <ve7jtb@ve7jtb.com>
If the AS is using asymmetric encryption = you need to both sign and then encrypt as anyone can encrypt. 

Yes if the client has a TLS cert you could use a jwk_uri = to keep the size down.

John = B.

On Nov 4, 2013, at 1:37 PM, = Nat Sakimura <sakimura@gmail.com> wrote:

Since the client_id is supposed to be opaque, it would = probably be better to JWE encrypt (note: all JWE encryption are = integrity protected as well) by the authorization server upon issuing it = to the client. This way, we have exactly one way of doing the things, = and it works for both symmetric and asymmetric case. 

I see this more useful in the case of symmetric client = secret. 

If the client were just using = public key crypto to authenticate itself to the server, using the URI of = the location of the client metadata as the client_id would = suffice. 

This has an advantage of smaller = client_id. 


2013/11/2 Hannes Tschofenig <hannes.tschofenig@gmx.net>
Hi John,

thanks for the super-quick response.


Am 01.11.13 19:18, schrieb John Bradley:

The client_id would continue to be opaque to the client as it is = now.
The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and
provide integrity if it is using a symmetric key (probably the
simplest thing if we are talking about a single registration = endpoint
paired with a single AS)  In more complicated scenarios where = perhaps
a group of AS share a single registration endpoint you probably want
to use asymmetric signature  then asymmetric encryption + = integrity.
Those are deployment decisions that need to be documented but can be
transparent to teh client.

Maybe it would be good to state that in the document that this is a = possible option without introducing further complications (other than = the verification procedure is different). If the AS signs the JWT then = it just needs to compare whether the issuer field matches what it had = previously put in there. If someone else signs the JWT then it needs to = check with some trust anchor store or something similar whether it = trusts that specific issuer.




Sorry to my mind it is obvious that the JWT would be integrity
protected/signed for all clients including clients using asymmetric
authentication to the token endpoint, and and
signed+encrypted+integrity for clients using symmetric
authentication.   That can be made clearer.

It would be good to say that because the effort is rather low and there = are benefits in doing so.



It might make sense to assume the issuer is just the AS but the AS
can do that without the benefit of a spec now, as there is no
interoperability issue.

The spec defining the JWT structure and signing and encryption
methods has the most benefit when you don't have such a tight
coupling between registration and AS.

That is likely why Justin and I didn't think a spec was necessary = for
the simple case other than to show people this is possible with the
existing registration spec.

I think there is value in providing that information for implementers = even though it does not require new extensions or so.



I am OK with strengthening the wording on signing/integrity
protecting and encryption.  eg if a symmetric key is included the = JWT
MUST be encrypted.

Cool.


I don't necessarily want to make any algorithm a must as that limits
algorithm agility in the future.
OK.



Thanks for giving it a read, see you Sunday I expect.
Unfortunately not since I am unable to attend the upcoming IETF meeting. = Derek will run the show.

Ciao
Hannes



John B.


On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig
<hannes.tschofenig@gmx.net> wrote:

Hi John, Hi all,

I read your document and here a few remarks.

In the dynamic client registration conference calls the topic of
the stateless client was raised since there was the argument in the
air that the current OAuth 2.0 RFC requires clients to be stateless
due to the nature of the client identifier.

It seems that you have found a way to make the client stateless
with regard to the client identifier (i.e., that the authorization
server does not need to store information about the client) by
dumping state information in the client identifier itself. In your
case you use a JWT, which is clever.

Since RFC 6749 explicitly says that the client identifier string
size is left undefined  and that the client should avoid making
assumptions about the identifier size I don't see a problem with
the proposed approach.

Now, there is one issue that I am wondering about. The client
identifier itself is not sufficient for authorizing the client (for
confidential clients). Instead, there is typically the need to have
a secret. Now, the secret is not conveyed in the JWT, at least not
in the way you have define it. You could of course do that and
there is a document that provides prior art, see
http://www.ietf.org/rfc/rfc5077 The story = essentially is that the
structure (JWT in your case) includes the key but of course then
you have to encrypt the entire blob.

In the case of public clients wouldn't you want to mandate at least
a digital signature or a keyed message digest for the JWT since
otherwise there is the risk that the client changes some of the
parameters to impersonate someone?

A few other questions:

* You write: "The issuer SHOULD sign the JWT with JWS in such a way
that the signature can be verified by the authorization server. "

I believe what you want to say is the following: The authorization
creates the client identifier (using the JWT) and the client does
not parse the received content since it treats it as opaque.
However, the authorization server MUST be able to process and
verify received client identifiers it previously created, which
requires to apply cryptographic processing when a JWT is signed
(using a JWS) and when a JWT is encrypted (using a JWE).

(I ignore the issue that I believe the JWT needs to be signed [for
public clients] and encrypted [for confidential clients].)

* You should submit the document as draft-bradley-oauth; this makes
it easier to find the document.

* You write: " The issuer MAY encrypt the JWT with JWE. "

I think you want to be stronger by saying that JWE MUST be used
when the authorization server wants to apply confidentiality
protection of the JWT. While the authorization server could use
other techniques as well the purpose of the document is to describe
one way to accomplish the goal and therefore it makes sense to be
specific.

I would even go as far as suggesting specific algorithms to use, as
an example.

* Although not stated directly I believe you allow the client
identifier to be created by a party other than the authorization
server. While this would theoretically make sense wouldn't it be
useful to just assume that the issuer is the authorization server?

Ciao Hannes _______________________________________________ = OAuth
mailing list OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
= https://www.ietf.org/mailman/listinfo/oauth



--
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
=




--
Nat Sakimura (=3Dnat)
Chairman, = OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


= --Apple-Mail=_D591B4E6-0317-45C9-B7C4-321BCBE02AB3-- From ve7jtb@ve7jtb.com Mon Nov 4 14:31:41 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF18121E821F for ; Mon, 4 Nov 2013 14:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC4TGfPtZ5ia for ; Mon, 4 Nov 2013 14:31:33 -0800 (PST) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by ietfa.amsl.com (Postfix) with ESMTP id BA42521E81F9 for ; Mon, 4 Nov 2013 14:31:29 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id kx10so7510172pab.40 for ; Mon, 04 Nov 2013 14:31:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ryKcQUuVtRR1hb1sMHlnlU3bNS69wXRKQU4xVj0nUWc=; b=idCDVi/ODXsniIYDohcsOAz6TZx1CcQQH4b81fq/zrtWZXdk+c1MEQiO/yEusgp6Tr tEDKwJ1sx8cROvUvucHI3BPSvVkHcHSsyFtOKx7mQZBmbcRu2TKzz/yf+PL7GxYvHSyq SUsZYtWrCDyFEVil+3FNfeRiOqOLXPqTvMEdVVp3uCLAzQpJOlLsiTzBNRi2X5lJMDpX 67/kV4n91ewNGnW07bVaDmka/0pk6zkSj2yy6keT2vnYxhJBpOS+pWHtgFWOtmH8LcGY G0SHuTAFZ9G28LvLTWpQe5WlE0RP9JrbQikDAsBLq825Mqsve7HsiqrrRErjsTs9VZbX TtYg== X-Gm-Message-State: ALoCoQlz6sTEsTVlhiiabSvPYtwmtPA6S6am1NSkoY4GvApHBh/F2Flu0G7CGmji03qt/FrE60wU X-Received: by 10.68.25.193 with SMTP id e1mr86662pbg.187.1383604289342; Mon, 04 Nov 2013 14:31:29 -0800 (PST) Received: from [192.168.6.17] (199-91-80-194.ip.van.radiant.net. [199.91.80.194]) by mx.google.com with ESMTPSA id wd6sm35631603pab.3.2013.11.04.14.31.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 14:31:28 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_556CB4AA-345B-4F2A-9170-A12D43C4D1D6"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: John Bradley In-Reply-To: Date: Mon, 4 Nov 2013 14:31:10 -0800 Message-Id: <7A18E261-2801-4FBD-9416-5C6DE9C5BC36@ve7jtb.com> References: <5273E5AD.7010408@gmx.net> <3F75FA0B-CAC3-439A-866B-CFE116FADA4E@ve7jtb.com> <5273F7A2.70409@gmx.net> <80c826af712c48a3bbb731861d2ca9cc@BY2PR03MB189.namprd03.prod.outlook.com> <10FAF55F-945B-48F1-BF30-BB0D1D85BC30@ve7jtb.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1816) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:31:41 -0000 --Apple-Mail=_556CB4AA-345B-4F2A-9170-A12D43C4D1D6 Content-Type: multipart/alternative; boundary="Apple-Mail=_3A5E44FB-4649-4A92-9D15-D3CCC69185B7" --Apple-Mail=_3A5E44FB-4649-4A92-9D15-D3CCC69185B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes we are talking about identification rather than authentication = though most people conflate the two. (I know you don't that is why you = are Dr Secure) We need to have the client identify itself via an assertion (in my = proposal carried as the client_id parameter, If we modify OAuth it = could be a separate parameter though I don't think that is necessary) = and a symmetric or asymmetric proof of possession mechanism so that = theft of the assertion will not allow the attacker to use it to exchange = code or refresh_token for access tokens. John B. On Nov 4, 2013, at 2:10 PM, Anthony Nadalin = wrote: > Identification is fine as long as it remains opaque and not specific = to any format. Authentication remains out of scope > =20 > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Monday, November 4, 2013 2:05 PM > To: Anthony Nadalin > Cc: Nat Sakimura; Hannes Tschofenig; oauth@ietf.org WG > Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 > =20 > The method the AS uses to identify the client is within the scope of = the WG. We have several drafts that relate to that topic of extending = that mechanism.=20 > =20 > What we are discussing is how best to do that securely without = requiring the AS to issue and maintain per client passwords. > =20 > John B. > =20 > =20 > On Nov 4, 2013, at 1:48 PM, Anthony Nadalin = wrote: >=20 >=20 > We need to avoid encoding secrets and authentication with client_id as = authentication is not part of our mission > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Nat Sakimura > Sent: Monday, November 4, 2013 1:38 PM > To: Hannes Tschofenig > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 > =20 > Since the client_id is supposed to be opaque, it would probably be = better to JWE encrypt (note: all JWE encryption are integrity protected = as well) by the authorization server upon issuing it to the client. This = way, we have exactly one way of doing the things, and it works for both = symmetric and asymmetric case.=20 > =20 > I see this more useful in the case of symmetric client secret.=20 > =20 > If the client were just using public key crypto to authenticate itself = to the server, using the URI of the location of the client metadata as = the client_id would suffice.=20 > =20 > This has an advantage of smaller client_id.=20 > =20 >=20 > 2013/11/2 Hannes Tschofenig > Hi John, >=20 > thanks for the super-quick response. >=20 >=20 > Am 01.11.13 19:18, schrieb John Bradley: > =20 > The client_id would continue to be opaque to the client as it is now. > The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and > provide integrity if it is using a symmetric key (probably the > simplest thing if we are talking about a single registration endpoint > paired with a single AS) In more complicated scenarios where perhaps > a group of AS share a single registration endpoint you probably want > to use asymmetric signature then asymmetric encryption + integrity. > Those are deployment decisions that need to be documented but can be > transparent to teh client. > =20 > Maybe it would be good to state that in the document that this is a = possible option without introducing further complications (other than = the verification procedure is different). If the AS signs the JWT then = it just needs to compare whether the issuer field matches what it had = previously put in there. If someone else signs the JWT then it needs to = check with some trust anchor store or something similar whether it = trusts that specific issuer. >=20 >=20 >=20 >=20 >=20 > Sorry to my mind it is obvious that the JWT would be integrity > protected/signed for all clients including clients using asymmetric > authentication to the token endpoint, and and > signed+encrypted+integrity for clients using symmetric > authentication. That can be made clearer. > =20 > It would be good to say that because the effort is rather low and = there are benefits in doing so. > =20 >=20 >=20 > It might make sense to assume the issuer is just the AS but the AS > can do that without the benefit of a spec now, as there is no > interoperability issue. >=20 > The spec defining the JWT structure and signing and encryption > methods has the most benefit when you don't have such a tight > coupling between registration and AS. >=20 > That is likely why Justin and I didn't think a spec was necessary for > the simple case other than to show people this is possible with the > existing registration spec. > =20 > I think there is value in providing that information for implementers = even though it does not require new extensions or so. > =20 >=20 >=20 > I am OK with strengthening the wording on signing/integrity > protecting and encryption. eg if a symmetric key is included the JWT > MUST be encrypted. > =20 > Cool. > =20 >=20 > I don't necessarily want to make any algorithm a must as that limits > algorithm agility in the future. > OK. > =20 >=20 >=20 > Thanks for giving it a read, see you Sunday I expect. > Unfortunately not since I am unable to attend the upcoming IETF = meeting. Derek will run the show. >=20 > Ciao > Hannes > =20 >=20 >=20 > John B. >=20 >=20 > On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig > wrote: >=20 > Hi John, Hi all, >=20 > I read your document and here a few remarks. >=20 > In the dynamic client registration conference calls the topic of > the stateless client was raised since there was the argument in the > air that the current OAuth 2.0 RFC requires clients to be stateless > due to the nature of the client identifier. >=20 > It seems that you have found a way to make the client stateless > with regard to the client identifier (i.e., that the authorization > server does not need to store information about the client) by > dumping state information in the client identifier itself. In your > case you use a JWT, which is clever. >=20 > Since RFC 6749 explicitly says that the client identifier string > size is left undefined and that the client should avoid making > assumptions about the identifier size I don't see a problem with > the proposed approach. >=20 > Now, there is one issue that I am wondering about. The client > identifier itself is not sufficient for authorizing the client (for > confidential clients). Instead, there is typically the need to have > a secret. Now, the secret is not conveyed in the JWT, at least not > in the way you have define it. You could of course do that and > there is a document that provides prior art, see > http://www.ietf.org/rfc/rfc5077 The story essentially is that the > structure (JWT in your case) includes the key but of course then > you have to encrypt the entire blob. >=20 > In the case of public clients wouldn't you want to mandate at least > a digital signature or a keyed message digest for the JWT since > otherwise there is the risk that the client changes some of the > parameters to impersonate someone? >=20 > A few other questions: >=20 > * You write: "The issuer SHOULD sign the JWT with JWS in such a way > that the signature can be verified by the authorization server. " >=20 > I believe what you want to say is the following: The authorization > creates the client identifier (using the JWT) and the client does > not parse the received content since it treats it as opaque. > However, the authorization server MUST be able to process and > verify received client identifiers it previously created, which > requires to apply cryptographic processing when a JWT is signed > (using a JWS) and when a JWT is encrypted (using a JWE). >=20 > (I ignore the issue that I believe the JWT needs to be signed [for > public clients] and encrypted [for confidential clients].) >=20 > * You should submit the document as draft-bradley-oauth; this makes > it easier to find the document. >=20 > * You write: " The issuer MAY encrypt the JWT with JWE. " >=20 > I think you want to be stronger by saying that JWE MUST be used > when the authorization server wants to apply confidentiality > protection of the JWT. While the authorization server could use > other techniques as well the purpose of the document is to describe > one way to accomplish the goal and therefore it makes sense to be > specific. >=20 > I would even go as far as suggesting specific algorithms to use, as > an example. >=20 > * Although not stated directly I believe you allow the client > identifier to be created by a party other than the authorization > server. While this would theoretically make sense wouldn't it be > useful to just assume that the issuer is the authorization server? >=20 > Ciao Hannes _______________________________________________ OAuth > mailing list OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > =20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_3A5E44FB-4649-4A92-9D15-D3CCC69185B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Yes we = are talking about identification rather than authentication though most = people conflate the two.  (I know you don't that is why you are Dr = Secure)

We need to have the client identify itself = via an assertion (in my proposal carried as the client_id parameter, =  If we modify OAuth it could be a separate parameter though I don't = think that is necessary)  and a symmetric or asymmetric proof of = possession mechanism so that theft of the assertion will not allow the = attacker to use it to exchange code or refresh_token for access = tokens.

John B.

On Nov = 4, 2013, at 2:10 PM, Anthony Nadalin <tonynad@microsoft.com> = wrote:

Identification is fine as long as it remains opaque = and not specific to any format. Authentication remains out of = scope
From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Monday, November 4, 2013 = 2:05 PM
To: Anthony = Nadalin
Cc: Nat Sakimura; Hannes = Tschofenig; oauth@ietf.org = WG
Subject: Re: [OAUTH-WG] = draft-bradley-stateless-oauth-client-00
 
The method the AS uses to identify the client is within the = scope of the WG.  We have several drafts that relate to that topic = of extending that mechanism. 
 
What we are discussing is how best to do that = securely without requiring the AS to issue and maintain per client = passwords.
 
John = B.
 
 
On = Nov 4, 2013, at 1:48 PM, Anthony Nadalin <tonynad@microsoft.com> = wrote:


We need to avoid encoding secrets and authentication = with client_id as authentication is not part of our = mission
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Nat = Sakimura
Sent: Monday, November 4, 2013 = 1:38 PM
To: Hannes = Tschofenig
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] = draft-bradley-stateless-oauth-client-00
=
 
Since the client_id is supposed to be opaque, it = would probably be better to JWE encrypt (note: all JWE encryption are = integrity protected as well) by the authorization server upon issuing it = to the client. This way, we have exactly one way of doing the things, = and it works for both symmetric and asymmetric = case. 
 
I see = this more useful in the case of symmetric client = secret. 
 
If = the client were just using public key crypto to authenticate itself to = the server, using the URI of the location of the client metadata as the = client_id would suffice. 
 
This has an advantage of smaller = client_id. 

 

2013/11/2 Hannes Tschofenig <hannes.tschofenig@gmx.net>
Hi John,

thanks for the super-quick = response.


Am 01.11.13 19:18, schrieb John = Bradley:
 
The client_id would continue to = be opaque to the client as it is now.
The AS can send a JWE using = AES_128_CBC_HMAC_SHA_256 to encrypt and
provide integrity if it is = using a symmetric key (probably the
simplest thing if we are talking = about a single registration endpoint
paired with a single AS) =  In more complicated scenarios where perhaps
a group of AS share = a single registration endpoint you probably want
to use asymmetric = signature  then asymmetric encryption + integrity.
Those are = deployment decisions that need to be documented but can = be
transparent to teh client.
 
Maybe it would be good to state that in the document = that this is a possible option without introducing further complications = (other than the verification procedure is different). If the AS signs = the JWT then it just needs to compare whether the issuer field matches = what it had previously put in there. If someone else signs the JWT then = it needs to check with some trust anchor store or something similar = whether it trusts that specific issuer.





Sorry to my mind it is = obvious that the JWT would be integrity
protected/signed for all = clients including clients using asymmetric
authentication to the = token endpoint, and and
signed+encrypted+integrity for clients using = symmetric
authentication.   That can be made = clearer.
 
It would be good to say that because the effort is rather low = and there are benefits in doing so.

 


It might make sense to = assume the issuer is just the AS but the AS
can do that without the = benefit of a spec now, as there is no
interoperability = issue.

The spec defining the JWT structure and signing and = encryption
methods has the most benefit when you don't have such a = tight
coupling between registration and AS.

That is likely why = Justin and I didn't think a spec was necessary for
the simple case = other than to show people this is possible with the
existing = registration spec.
 
I think there is value in providing that information for = implementers even though it does not require new extensions or = so.

 


I am OK with strengthening = the wording on signing/integrity
protecting and encryption.  eg = if a symmetric key is included the JWT
MUST be = encrypted.
 
Cool.
 

I don't necessarily want to = make any algorithm a must as that limits
algorithm agility in the = future.
OK.

 


Thanks for giving it a read, = see you Sunday I expect.
Unfortunately not since I am unable to attend the = upcoming IETF meeting. Derek will run the show.

Ciao
Hannes

 


John = B.


On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig
<hannes.tschofenig@gmx.net> = wrote:

Hi John, Hi all,

I read your document and = here a few remarks.

In the dynamic client registration conference = calls the topic of
the stateless client was raised since there was = the argument in the
air that the current OAuth 2.0 RFC requires = clients to be stateless
due to the nature of the client = identifier.

It seems that you have found a way to make the client = stateless
with regard to the client identifier (i.e., that the = authorization
server does not need to store information about the = client) by
dumping state information in the client identifier itself. = In your
case you use a JWT, which is clever.

Since RFC 6749 = explicitly says that the client identifier string
size is left = undefined  and that the client should avoid making
assumptions = about the identifier size I don't see a problem with
the proposed = approach.

Now, there is one issue that I am wondering about. The = client
identifier itself is not sufficient for authorizing the client = (for
confidential clients). Instead, there is typically the need to = have
a secret. Now, the secret is not conveyed in the JWT, at least = not
in the way you have define it. You could of course do that = and
there is a document that provides prior art, see
http://www.ietf.org/rfc/rfc5077 The story essentially is = that the
structure (JWT in your case) includes the key but of course = then
you have to encrypt the entire blob.

In the case of = public clients wouldn't you want to mandate at least
a digital = signature or a keyed message digest for the JWT since
otherwise there = is the risk that the client changes some of the
parameters to = impersonate someone?

A few other questions:

* You write: = "The issuer SHOULD sign the JWT with JWS in such a way
that the = signature can be verified by the authorization server. "

I = believe what you want to say is the following: The = authorization
creates the client identifier (using the JWT) and the = client does
not parse the received content since it treats it as = opaque.
However, the authorization server MUST be able to process = and
verify received client identifiers it previously created, = which
requires to apply cryptographic processing when a JWT is = signed
(using a JWS) and when a JWT is encrypted (using a = JWE).

(I ignore the issue that I believe the JWT needs to be = signed [for
public clients] and encrypted [for confidential = clients].)

* You should submit the document as = draft-bradley-oauth; this makes
it easier to find the = document.

* You write: " The issuer MAY encrypt the JWT with JWE. = "

I think you want to be stronger by saying that JWE MUST be = used
when the authorization server wants to apply = confidentiality
protection of the JWT. While the authorization server = could use
other techniques as well the purpose of the document is to = describe
one way to accomplish the goal and therefore it makes sense = to be
specific.

I would even go as far as suggesting specific = algorithms to use, as
an example.

* Although not stated = directly I believe you allow the client
identifier to be created by a = party other than the authorization
server. While this would = theoretically make sense wouldn't it be
useful to just assume that = the issuer is the authorization server?

Ciao Hannes = _______________________________________________ OAuth
mailing = list OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth=
 

_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth=


 
-- 
Nat Sakimura = (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
<= /div>
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= = --Apple-Mail=_3A5E44FB-4649-4A92-9D15-D3CCC69185B7-- --Apple-Mail=_556CB4AA-345B-4F2A-9170-A12D43C4D1D6 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMTA0MjIzMTExWjAjBgkqhkiG9w0BCQQxFgQUCdO7MrlB e+zRRU2z0LqB6yUs8OMwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAjfHRa9fHukITb4yh8AXEylMNiflrIAyKhJDeaBV7 UTgbNyNpttcUFK40f8u1/bLn1kdHVh4ZCAcEbkVGF7dFsn1zTJ2493FtjNHQ4CLYIwRuY4+FuZaK mX1Zt8qzFBhFnpnnW0w396muXs5x2mqswtUMBISwDX56yJ4c5HSPX+hilCAUQNJH5ORwEvgTYonV q9coWnitUr6GQhH9vtW3iU3gX51pDD4y0RigTPDLn0+KQ4pC7CmcMCddodtIp+5VisAS9P7Ev5Gz 9de1lL9vDH5FwTr7YyVL1hBW7lY0JxsLBGplEFnX/cgEcaMsX1XZDUunPl3IRC8CYcZYUai0nQAA AAAAAA== --Apple-Mail=_556CB4AA-345B-4F2A-9170-A12D43C4D1D6-- From phil.hunt@oracle.com Mon Nov 4 14:42:53 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B5621E80E1 for ; Mon, 4 Nov 2013 14:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.413 X-Spam-Level: X-Spam-Status: No, score=-5.413 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnDyOaRcCMdK for ; Mon, 4 Nov 2013 14:42:48 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id C14FB21E8122 for ; Mon, 4 Nov 2013 14:42:45 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA4Mghn8005198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Nov 2013 22:42:44 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA4Mgg07006071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Nov 2013 22:42:42 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA4MggIJ010516; Mon, 4 Nov 2013 22:42:42 GMT Received: from dhcp-a540.meeting.ietf.org (/31.133.165.64) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Nov 2013 14:42:42 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_235EC4F6-83C1-41F9-8E84-5E5729DAD2C9" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <82A7937E-1A09-4655-977C-43F6C7C1D17F@ve7jtb.com> Date: Mon, 4 Nov 2013 14:42:40 -0800 Message-Id: References: <5273E5AD.7010408@gmx.net> <3F75FA0B-CAC3-439A-866B-CFE116FADA4E@ve7jtb.com> <5273F7A2.70409@gmx.net> <4F8C451C-FD59-43DC-B2F4-65EA2FF52DDC@oracle.com> <82A7937E-1A09-4655-977C-43F6C7C1D17F@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:42:53 -0000 --Apple-Mail=_235EC4F6-83C1-41F9-8E84-5E5729DAD2C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I see. It was buried under "reg". Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-11-04, at 2:22 PM, John Bradley wrote: > If you read the draft the redirect URI and other parameters are = encoded into the JWT assertion.=20 >=20 > What we are proposing is using an assertion/token as the client_id = that assertion cannot be a bearer assertion for confidential clients, = that would be inssecure. > IT needs to be some sort of proof of possession assertion/token. = There are several ways to do proof of possession one is including a = public key and the other is encrypting a symmetric key. >=20 > The option I didn't include is using some sort of key derivation = mechanism, DH etc so that you don't need to encrypt if using a symmetric = password. >=20 > Symmetric passwords have all sorts of problems. A static assertion = without PoP has similar problems with securing it in the client. >=20 > For reference the sort of compromises I am concerned about are already = starting to happen. > = http://blog.programmableweb.com/2013/11/04/why-the-attack-on-buffer-was-a-= serious-wake-up-call-for-the-web/ >=20 > John B. >=20 > On Nov 4, 2013, at 2:06 PM, Phil Hunt wrote: >=20 >> So how is a stateless client able to do the authorize flow? How does = the server know about the redirect_url? Is it wide open? >>=20 >> Still would like to hear more about this. Sometimes attacking the = problem from a different direction leads to an innovative conclusion. >>=20 >> Still I share the concerns of Tony and binding authentication into = client_id. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >> On 2013-11-04, at 1:58 PM, Nat Sakimura wrote: >>=20 >>> I was assuming that the AS uses symmetric encryption as it is faster = and it just needs to be encrypted and decoded by itself.=20 >>>=20 >>>=20 >>> 2013/11/5 John Bradley >>> If the AS is using asymmetric encryption you need to both sign and = then encrypt as anyone can encrypt.=20 >>>=20 >>> Yes if the client has a TLS cert you could use a jwk_uri to keep the = size down. >>>=20 >>> John B. >>>=20 >>> On Nov 4, 2013, at 1:37 PM, Nat Sakimura wrote: >>>=20 >>>> Since the client_id is supposed to be opaque, it would probably be = better to JWE encrypt (note: all JWE encryption are integrity protected = as well) by the authorization server upon issuing it to the client. This = way, we have exactly one way of doing the things, and it works for both = symmetric and asymmetric case.=20 >>>>=20 >>>> I see this more useful in the case of symmetric client secret.=20 >>>>=20 >>>> If the client were just using public key crypto to authenticate = itself to the server, using the URI of the location of the client = metadata as the client_id would suffice.=20 >>>>=20 >>>> This has an advantage of smaller client_id.=20 >>>>=20 >>>>=20 >>>> 2013/11/2 Hannes Tschofenig >>>> Hi John, >>>>=20 >>>> thanks for the super-quick response. >>>>=20 >>>>=20 >>>> Am 01.11.13 19:18, schrieb John Bradley: >>>>=20 >>>> The client_id would continue to be opaque to the client as it is = now. >>>> The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and >>>> provide integrity if it is using a symmetric key (probably the >>>> simplest thing if we are talking about a single registration = endpoint >>>> paired with a single AS) In more complicated scenarios where = perhaps >>>> a group of AS share a single registration endpoint you probably = want >>>> to use asymmetric signature then asymmetric encryption + = integrity. >>>> Those are deployment decisions that need to be documented but can = be >>>> transparent to teh client. >>>>=20 >>>> Maybe it would be good to state that in the document that this is a = possible option without introducing further complications (other than = the verification procedure is different). If the AS signs the JWT then = it just needs to compare whether the issuer field matches what it had = previously put in there. If someone else signs the JWT then it needs to = check with some trust anchor store or something similar whether it = trusts that specific issuer. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Sorry to my mind it is obvious that the JWT would be integrity >>>> protected/signed for all clients including clients using asymmetric >>>> authentication to the token endpoint, and and >>>> signed+encrypted+integrity for clients using symmetric >>>> authentication. That can be made clearer. >>>>=20 >>>> It would be good to say that because the effort is rather low and = there are benefits in doing so. >>>>=20 >>>>=20 >>>>=20 >>>> It might make sense to assume the issuer is just the AS but the AS >>>> can do that without the benefit of a spec now, as there is no >>>> interoperability issue. >>>>=20 >>>> The spec defining the JWT structure and signing and encryption >>>> methods has the most benefit when you don't have such a tight >>>> coupling between registration and AS. >>>>=20 >>>> That is likely why Justin and I didn't think a spec was necessary = for >>>> the simple case other than to show people this is possible with the >>>> existing registration spec. >>>>=20 >>>> I think there is value in providing that information for = implementers even though it does not require new extensions or so. >>>>=20 >>>>=20 >>>>=20 >>>> I am OK with strengthening the wording on signing/integrity >>>> protecting and encryption. eg if a symmetric key is included the = JWT >>>> MUST be encrypted. >>>>=20 >>>> Cool. >>>>=20 >>>>=20 >>>> I don't necessarily want to make any algorithm a must as that = limits >>>> algorithm agility in the future. >>>> OK. >>>>=20 >>>>=20 >>>>=20 >>>> Thanks for giving it a read, see you Sunday I expect. >>>> Unfortunately not since I am unable to attend the upcoming IETF = meeting. Derek will run the show. >>>>=20 >>>> Ciao >>>> Hannes >>>>=20 >>>>=20 >>>>=20 >>>> John B. >>>>=20 >>>>=20 >>>> On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig >>>> wrote: >>>>=20 >>>> Hi John, Hi all, >>>>=20 >>>> I read your document and here a few remarks. >>>>=20 >>>> In the dynamic client registration conference calls the topic of >>>> the stateless client was raised since there was the argument in the >>>> air that the current OAuth 2.0 RFC requires clients to be stateless >>>> due to the nature of the client identifier. >>>>=20 >>>> It seems that you have found a way to make the client stateless >>>> with regard to the client identifier (i.e., that the authorization >>>> server does not need to store information about the client) by >>>> dumping state information in the client identifier itself. In your >>>> case you use a JWT, which is clever. >>>>=20 >>>> Since RFC 6749 explicitly says that the client identifier string >>>> size is left undefined and that the client should avoid making >>>> assumptions about the identifier size I don't see a problem with >>>> the proposed approach. >>>>=20 >>>> Now, there is one issue that I am wondering about. The client >>>> identifier itself is not sufficient for authorizing the client (for >>>> confidential clients). Instead, there is typically the need to have >>>> a secret. Now, the secret is not conveyed in the JWT, at least not >>>> in the way you have define it. You could of course do that and >>>> there is a document that provides prior art, see >>>> http://www.ietf.org/rfc/rfc5077 The story essentially is that the >>>> structure (JWT in your case) includes the key but of course then >>>> you have to encrypt the entire blob. >>>>=20 >>>> In the case of public clients wouldn't you want to mandate at least >>>> a digital signature or a keyed message digest for the JWT since >>>> otherwise there is the risk that the client changes some of the >>>> parameters to impersonate someone? >>>>=20 >>>> A few other questions: >>>>=20 >>>> * You write: "The issuer SHOULD sign the JWT with JWS in such a way >>>> that the signature can be verified by the authorization server. " >>>>=20 >>>> I believe what you want to say is the following: The authorization >>>> creates the client identifier (using the JWT) and the client does >>>> not parse the received content since it treats it as opaque. >>>> However, the authorization server MUST be able to process and >>>> verify received client identifiers it previously created, which >>>> requires to apply cryptographic processing when a JWT is signed >>>> (using a JWS) and when a JWT is encrypted (using a JWE). >>>>=20 >>>> (I ignore the issue that I believe the JWT needs to be signed [for >>>> public clients] and encrypted [for confidential clients].) >>>>=20 >>>> * You should submit the document as draft-bradley-oauth; this makes >>>> it easier to find the document. >>>>=20 >>>> * You write: " The issuer MAY encrypt the JWT with JWE. " >>>>=20 >>>> I think you want to be stronger by saying that JWE MUST be used >>>> when the authorization server wants to apply confidentiality >>>> protection of the JWT. While the authorization server could use >>>> other techniques as well the purpose of the document is to describe >>>> one way to accomplish the goal and therefore it makes sense to be >>>> specific. >>>>=20 >>>> I would even go as far as suggesting specific algorithms to use, as >>>> an example. >>>>=20 >>>> * Although not stated directly I believe you allow the client >>>> identifier to be created by a party other than the authorization >>>> server. While this would theoretically make sense wouldn't it be >>>> useful to just assume that the issuer is the authorization server? >>>>=20 >>>> Ciao Hannes _______________________________________________ OAuth >>>> mailing list OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> Nat Sakimura (=3Dnat) >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>> Nat Sakimura (=3Dnat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 --Apple-Mail=_235EC4F6-83C1-41F9-8E84-5E5729DAD2C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I = see. It was buried under "reg".


On 2013-11-04, at 2:22 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

If you read the draft the redirect URI and other = parameters are encoded into the JWT = assertion. 

What we are proposing is using an = assertion/token as the client_id that assertion cannot be a bearer = assertion for confidential clients, that would be = inssecure.
IT needs to be some sort of proof of possession = assertion/token.   There are several ways to do proof of possession = one is including a public key and the other is encrypting a symmetric = key.

The option I didn't include is using some = sort of key derivation mechanism, DH etc so that you don't need to = encrypt if using a symmetric = password.

Symmetric passwords have all sorts of = problems.   A static assertion without PoP has similar problems = with securing it in the client.

For reference = the sort of compromises I am concerned about are already starting to = happen.

John = B.

On Nov 4, 2013, at 2:06 PM, Phil = Hunt <phil.hunt@oracle.com> = wrote:

So = how is a stateless client able to do the authorize flow?  How does = the server know about the redirect_url?  Is it wide = open?

Still would like to hear more about this. =  Sometimes attacking the problem from a different direction leads = to an innovative conclusion.

Still I share the = concerns of Tony and binding authentication into = client_id.
www.independentid.com
phil.hunt@oracle.com
=

On 2013-11-04, at 1:58 PM, Nat Sakimura <sakimura@gmail.com> = wrote:

I was assuming that the AS uses symmetric = encryption as it is faster and it just needs to be encrypted and decoded = by itself. 


2013/11/5 John Bradley <ve7jtb@ve7jtb.com>
If the AS is using asymmetric encryption = you need to both sign and then encrypt as anyone can encrypt. 

Yes if the client has a TLS cert you could use a jwk_uri = to keep the size down.

John = B.

On Nov 4, 2013, at 1:37 PM, = Nat Sakimura <sakimura@gmail.com> wrote:

Since the client_id is supposed to be opaque, it would = probably be better to JWE encrypt (note: all JWE encryption are = integrity protected as well) by the authorization server upon issuing it = to the client. This way, we have exactly one way of doing the things, = and it works for both symmetric and asymmetric case. 

I see this more useful in the case of symmetric client = secret. 

If the client were just using = public key crypto to authenticate itself to the server, using the URI of = the location of the client metadata as the client_id would = suffice. 

This has an advantage of smaller = client_id. 


2013/11/2 Hannes Tschofenig <hannes.tschofenig@gmx.net>
Hi John,

thanks for the super-quick response.


Am 01.11.13 19:18, schrieb John Bradley:

The client_id would continue to be opaque to the client as it is = now.
The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and
provide integrity if it is using a symmetric key (probably the
simplest thing if we are talking about a single registration = endpoint
paired with a single AS)  In more complicated scenarios where = perhaps
a group of AS share a single registration endpoint you probably want
to use asymmetric signature  then asymmetric encryption + = integrity.
Those are deployment decisions that need to be documented but can be
transparent to teh client.

Maybe it would be good to state that in the document that this is a = possible option without introducing further complications (other than = the verification procedure is different). If the AS signs the JWT then = it just needs to compare whether the issuer field matches what it had = previously put in there. If someone else signs the JWT then it needs to = check with some trust anchor store or something similar whether it = trusts that specific issuer.




Sorry to my mind it is obvious that the JWT would be integrity
protected/signed for all clients including clients using asymmetric
authentication to the token endpoint, and and
signed+encrypted+integrity for clients using symmetric
authentication.   That can be made clearer.

It would be good to say that because the effort is rather low and there = are benefits in doing so.



It might make sense to assume the issuer is just the AS but the AS
can do that without the benefit of a spec now, as there is no
interoperability issue.

The spec defining the JWT structure and signing and encryption
methods has the most benefit when you don't have such a tight
coupling between registration and AS.

That is likely why Justin and I didn't think a spec was necessary = for
the simple case other than to show people this is possible with the
existing registration spec.

I think there is value in providing that information for implementers = even though it does not require new extensions or so.



I am OK with strengthening the wording on signing/integrity
protecting and encryption.  eg if a symmetric key is included the = JWT
MUST be encrypted.

Cool.


I don't necessarily want to make any algorithm a must as that limits
algorithm agility in the future.
OK.



Thanks for giving it a read, see you Sunday I expect.
Unfortunately not since I am unable to attend the upcoming IETF meeting. = Derek will run the show.

Ciao
Hannes



John B.


On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig
<hannes.tschofenig@gmx.net> wrote:

Hi John, Hi all,

I read your document and here a few remarks.

In the dynamic client registration conference calls the topic of
the stateless client was raised since there was the argument in the
air that the current OAuth 2.0 RFC requires clients to be stateless
due to the nature of the client identifier.

It seems that you have found a way to make the client stateless
with regard to the client identifier (i.e., that the authorization
server does not need to store information about the client) by
dumping state information in the client identifier itself. In your
case you use a JWT, which is clever.

Since RFC 6749 explicitly says that the client identifier string
size is left undefined  and that the client should avoid making
assumptions about the identifier size I don't see a problem with
the proposed approach.

Now, there is one issue that I am wondering about. The client
identifier itself is not sufficient for authorizing the client (for
confidential clients). Instead, there is typically the need to have
a secret. Now, the secret is not conveyed in the JWT, at least not
in the way you have define it. You could of course do that and
there is a document that provides prior art, see
http://www.ietf.org/rfc/rfc5077 The story = essentially is that the
structure (JWT in your case) includes the key but of course then
you have to encrypt the entire blob.

In the case of public clients wouldn't you want to mandate at least
a digital signature or a keyed message digest for the JWT since
otherwise there is the risk that the client changes some of the
parameters to impersonate someone?

A few other questions:

* You write: "The issuer SHOULD sign the JWT with JWS in such a way
that the signature can be verified by the authorization server. "

I believe what you want to say is the following: The authorization
creates the client identifier (using the JWT) and the client does
not parse the received content since it treats it as opaque.
However, the authorization server MUST be able to process and
verify received client identifiers it previously created, which
requires to apply cryptographic processing when a JWT is signed
(using a JWS) and when a JWT is encrypted (using a JWE).

(I ignore the issue that I believe the JWT needs to be signed [for
public clients] and encrypted [for confidential clients].)

* You should submit the document as draft-bradley-oauth; this makes
it easier to find the document.

* You write: " The issuer MAY encrypt the JWT with JWE. "

I think you want to be stronger by saying that JWE MUST be used
when the authorization server wants to apply confidentiality
protection of the JWT. While the authorization server could use
other techniques as well the purpose of the document is to describe
one way to accomplish the goal and therefore it makes sense to be
specific.

I would even go as far as suggesting specific algorithms to use, as
an example.

* Although not stated directly I believe you allow the client
identifier to be created by a party other than the authorization
server. While this would theoretically make sense wouldn't it be
useful to just assume that the issuer is the authorization server?

Ciao Hannes _______________________________________________ = OAuth
mailing list OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
= https://www.ietf.org/mailman/listinfo/oauth



--
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
=




--
Nat Sakimura (=3Dnat)
Chairman, = OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth



= --Apple-Mail=_235EC4F6-83C1-41F9-8E84-5E5729DAD2C9-- From phil.hunt@oracle.com Mon Nov 4 15:13:02 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892CD21E8271 for ; Mon, 4 Nov 2013 15:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.236 X-Spam-Level: X-Spam-Status: No, score=-6.236 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-tIq-h1Ujlk for ; Mon, 4 Nov 2013 15:12:57 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 63BF511E81F5 for ; Mon, 4 Nov 2013 15:12:56 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA4NCtAa029351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 4 Nov 2013 23:12:55 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA4NCslG028154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 Nov 2013 23:12:55 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA4NCs31028143 for ; Mon, 4 Nov 2013 23:12:54 GMT Received: from dhcp-a540.meeting.ietf.org (/31.133.165.64) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Nov 2013 15:12:54 -0800 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_74C95611-D799-4389-AAEE-7566DD521FE7" Date: Mon, 4 Nov 2013 15:12:51 -0800 Message-Id: <000F54A2-D1EC-4608-9C64-8FCD9D5E0311@oracle.com> To: PRATEEK MISHRA Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org WG" Subject: [OAUTH-WG] expired hotk spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 23:13:02 -0000 --Apple-Mail=_74C95611-D799-4389-AAEE-7566DD521FE7 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii https://datatracker.ietf.org/doc/draft-tschofenig-oauth-hotk/ Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_74C95611-D799-4389-AAEE-7566DD521FE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii htt= ps://datatracker.ietf.org/doc/draft-tschofenig-oauth-hotk/

Phil

@independentid
www.independ= entid.com
phil.hunt@oracle.com
=

= --Apple-Mail=_74C95611-D799-4389-AAEE-7566DD521FE7-- From jricher@mitre.org Tue Nov 5 15:02:05 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F6C11E8179 for ; Tue, 5 Nov 2013 15:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.341 X-Spam-Level: X-Spam-Status: No, score=-6.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Xk-7bTJ3PaW for ; Tue, 5 Nov 2013 15:01:59 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A8E0211E814F for ; Tue, 5 Nov 2013 15:01:59 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2BDD51F05CC for ; Tue, 5 Nov 2013 18:01:59 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0A8C61F05AD for ; Tue, 5 Nov 2013 18:01:59 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.251]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0158.001; Tue, 5 Nov 2013 18:01:58 -0500 From: "Richer, Justin P." To: "oauth@ietf.org WG" Thread-Topic: IETF WG Follow-up Thread-Index: AQHO2nsHp2zTTchBW0Cml/XgPnOUXw== Date: Tue, 5 Nov 2013 23:01:57 +0000 Message-ID: <625DD549-A737-4A49-963C-A6AC503BBA11@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.6.132] Content-Type: text/plain; charset="us-ascii" Content-ID: <7AB211A5649F7446AE2E6FADD41E42D2@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] IETF WG Follow-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 23:02:05 -0000 At the end of Monday's WG session here at IETF, Derek suggested that severa= l of us who are here ought to get together and hash out some detailed solut= ions to Dyn-Reg and related issues in person while we have the opportunity.= As such, I suggest that those of us who are interested get together either= tomorrow after the morning plenary session or on Thursday after the JOSE s= ession. I'm personally here for the remainder of the week so I'm open to ot= her concrete suggestions as well. I'm even willing to bring my laptop along and we can try doing live spec su= rgery if it comes to that. -- Justin= From torsten@lodderstedt.net Tue Nov 5 15:05:50 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A109821F9DAA for ; Tue, 5 Nov 2013 15:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5e69ytEkgQW7 for ; Tue, 5 Nov 2013 15:05:44 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.97]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5BF21F9DD5 for ; Tue, 5 Nov 2013 15:05:43 -0800 (PST) Received: from [206.87.108.174] (helo=dhcp-00-26-b0-b5-9a-59.ubcvisitor.wifi.ubc.ca) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1Vdpgr-00083r-PL; Wed, 06 Nov 2013 00:05:42 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <625DD549-A737-4A49-963C-A6AC503BBA11@mitre.org> References: <625DD549-A737-4A49-963C-A6AC503BBA11@mitre.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----227BCQXNTZB9X5IEIZL8BICQ4E0FGE" From: Torsten Lodderstedt Date: Tue, 05 Nov 2013 15:05:30 -0800 To: "Richer, Justin P." , "oauth@ietf.org WG" Message-ID: X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [OAUTH-WG] IETF WG Follow-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 23:05:51 -0000 ------227BCQXNTZB9X5IEIZL8BICQ4E0FGE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Justin, I would like to meet tomorrow (as I'm leaving on Thursday). I'm also willed to prepare a concrete proposal. Thoughts? Regards, Torsten. "Richer, Justin P." schrieb: >At the end of Monday's WG session here at IETF, Derek suggested that >several of us who are here ought to get together and hash out some >detailed solutions to Dyn-Reg and related issues in person while we >have the opportunity. As such, I suggest that those of us who are >interested get together either tomorrow after the morning plenary >session or on Thursday after the JOSE session. I'm personally here for >the remainder of the week so I'm open to other concrete suggestions as >well. > >I'm even willing to bring my laptop along and we can try doing live >spec surgery if it comes to that. > > -- Justin >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth ------227BCQXNTZB9X5IEIZL8BICQ4E0FGE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Justin,

I would like to meet tomorrow (as I'm leaving on Thursday). I'm also willed to prepare a concrete proposal. Thoughts?

Regards,
Torsten.



"Richer, Justin P." <jricher@mitre.org> schrieb:
At the end of Monday's WG session here at IETF, Derek suggested that several of us who are here ought to get together and hash out some detailed solutions to Dyn-Reg and related issues in person while we have the opportunity. As such, I suggest that those of us who are interested get together either tomorrow after the morning plenary session or on Thursday after the JOSE session. I'm personally here for the remainder of the week so I'm open to other concrete suggestions as well.

I'm even willing to bring my laptop along and we can try doing live spec surgery if it comes to that.

-- Justin

OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
------227BCQXNTZB9X5IEIZL8BICQ4E0FGE-- From mamille2@cisco.com Tue Nov 5 15:28:49 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371E111E80F7 for ; Tue, 5 Nov 2013 15:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4L+6MIrUnD8v for ; Tue, 5 Nov 2013 15:28:41 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id EF48911E8169 for ; Tue, 5 Nov 2013 15:28:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1995; q=dns/txt; s=iport; t=1383694121; x=1384903721; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HxIzH24EYkbQ8KNOs5buldmp0hgMIZ7h2R0qwYRms2s=; b=KYcGDC+FoejpMA/8++uvxNwpoEWCmf6cau8Xplcx7GPfZl8e+CPynKeZ R+jFSt7CvoGY3ppP/vj2so3uapx8C9Td1dccC3xCTtIxnYnWR6LICHjXz AEyhyqPHgd+mLCZ19YIkt9garWuT1ME5ay2PuJeuVf67ttSMp5rJe7qRE I=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAFd+eVKtJV2a/2dsb2JhbABZgweBC79HgSYWdIIlAQEBAwF5BQsCAQhGMiUCBA4FDg2HYAa+cY9ZB4MggQ8DkC6BMIYskgmDJoIq X-IronPort-AV: E=Sophos;i="4.93,642,1378857600"; d="asc'?scan'208";a="278162850" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 05 Nov 2013 23:28:38 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA5NSbrw001004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 23:28:37 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.19]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 17:28:37 -0600 From: "Matt Miller (mamille2)" To: "Richer, Justin P." Thread-Topic: [OAUTH-WG] IETF WG Follow-up Thread-Index: AQHO2nsHp2zTTchBW0Cml/XgPnOUX5oXrR4A Date: Tue, 5 Nov 2013 23:28:36 +0000 Message-ID: <04942DC4-C5C4-431A-80C9-0EC855285430@cisco.com> References: <625DD549-A737-4A49-963C-A6AC503BBA11@mitre.org> In-Reply-To: <625DD549-A737-4A49-963C-A6AC503BBA11@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.115.46] Content-Type: multipart/signed; boundary="Apple-Mail=_F8D6DFD8-945A-45ED-98E5-B28F13151313"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] IETF WG Follow-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 23:28:49 -0000 --Apple-Mail=_F8D6DFD8-945A-45ED-98E5-B28F13151313 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 5, 2013, at 3:01 PM, Richer, Justin P. wrote: > At the end of Monday's WG session here at IETF, Derek suggested that = several of us who are here ought to get together and hash out some = detailed solutions to Dyn-Reg and related issues in person while we have = the opportunity. As such, I suggest that those of us who are interested = get together either tomorrow after the morning plenary session or on = Thursday after the JOSE session. I'm personally here for the remainder = of the week so I'm open to other concrete suggestions as well. >=20 > I'm even willing to bring my laptop along and we can try doing live = spec surgery if it comes to that. >=20 I fully support this action, but unfortunately I'm not sure I personally = can participate before Friday afternoon. I'm not entirely sure how much = benefit I can provide directly, but am more than willing to review the = output. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_F8D6DFD8-945A-45ED-98E5-B28F13151313 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSeX8kAAoJEDWi+S0W7cO1ojAH/3kc9qjN5oH6EUVwvL9iQOeH X7uDHnC0aVTmEFoGCq52X6QgoWz1ByWBOvl9IiK5m7jqxEfzB6h4RrpPD6ophvHq ptxk2vx89tqia5PQrlDiKmacv9j22jkf7AEqCGkLcPuVrx7MqCehE+tstBy5JAjP HzKo3FsAEuzs5HBvqxsoLEqKxmQNII/vWygXJXxUkACODapTG3wHyysO1WphsIsl 5yhDzjzq8KsFqZOuJ4BEQOAaics7SKkdRe+NxjonNwnxSkknshogZewcIdIBs61u 1s/FqV++5MTb/dSIteUDAqqk/v5/txk6755EsD1enVMY5HaYDUnib9qdzrn4uMM= =bt5h -----END PGP SIGNATURE----- --Apple-Mail=_F8D6DFD8-945A-45ED-98E5-B28F13151313-- From jricher@mitre.org Tue Nov 5 16:08:21 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF9C11E811A for ; Tue, 5 Nov 2013 16:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.358 X-Spam-Level: X-Spam-Status: No, score=-6.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtzqg2EVFUwY for ; Tue, 5 Nov 2013 16:08:14 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B06B111E8169 for ; Tue, 5 Nov 2013 16:08:14 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4ACAE1F048E; Tue, 5 Nov 2013 19:08:14 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 34DDD1F0235; Tue, 5 Nov 2013 19:08:14 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.251]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0158.001; Tue, 5 Nov 2013 19:08:14 -0500 From: "Richer, Justin P." To: "Matt Miller (mamille2)" Thread-Topic: [OAUTH-WG] IETF WG Follow-up Thread-Index: AQHO2nsHp2zTTchBW0Cml/XgPnOUX5oXrR4A///6ToA= Date: Wed, 6 Nov 2013 00:08:13 +0000 Message-ID: <65180FE6-B4CA-4E24-A49A-81D7A9839CFC@mitre.org> References: <625DD549-A737-4A49-963C-A6AC503BBA11@mitre.org> <04942DC4-C5C4-431A-80C9-0EC855285430@cisco.com> In-Reply-To: <04942DC4-C5C4-431A-80C9-0EC855285430@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.6.132] Content-Type: text/plain; charset="us-ascii" Content-ID: <3B958C3AD9AF684F8776BB206447ADFB@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] IETF WG Follow-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 00:08:21 -0000 All output will be published back to the list for further discussion and ap= proval in all cases. -- Justin On Nov 5, 2013, at 3:28 PM, "Matt Miller (mamille2)" wrote: >=20 > On Nov 5, 2013, at 3:01 PM, Richer, Justin P. wrote: >=20 >> At the end of Monday's WG session here at IETF, Derek suggested that sev= eral of us who are here ought to get together and hash out some detailed so= lutions to Dyn-Reg and related issues in person while we have the opportuni= ty. As such, I suggest that those of us who are interested get together eit= her tomorrow after the morning plenary session or on Thursday after the JOS= E session. I'm personally here for the remainder of the week so I'm open to= other concrete suggestions as well. >>=20 >> I'm even willing to bring my laptop along and we can try doing live spec= surgery if it comes to that. >>=20 >=20 > I fully support this action, but unfortunately I'm not sure I personally = can participate before Friday afternoon. I'm not entirely sure how much be= nefit I can provide directly, but am more than willing to review the output= . >=20 >=20 > - m&m >=20 > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. >=20 From bcampbell@pingidentity.com Tue Nov 5 16:12:22 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D115A21E80BA for ; Tue, 5 Nov 2013 16:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.94 X-Spam-Level: X-Spam-Status: No, score=-5.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0gFs47eFraS for ; Tue, 5 Nov 2013 16:12:17 -0800 (PST) Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) by ietfa.amsl.com (Postfix) with ESMTP id C32EB21F9DFB for ; Tue, 5 Nov 2013 16:12:17 -0800 (PST) Received: from mail-ie0-f180.google.com ([209.85.223.180]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP ID DSNKUnmJW1JVgc+/+T5xCPvHdZcxIesPVGns@postini.com; Tue, 05 Nov 2013 16:12:17 PST Received: by mail-ie0-f180.google.com with SMTP id e14so15716640iej.25 for ; Tue, 05 Nov 2013 16:11:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Dq9dYHLleafqc5HArZ0H2snYJg/oYlUDQ2idP2Ngv5U=; b=caG8xUmIBZVcPCNWiTtpaZhxvYQWFTk1R4SpkxAWMjFJgxLcC2Qf35M4VFPq+WP8Wa +THR22Yvv5Mu6CK7ec19ibPaA9uBbx0aFG07bl9DQsUPrMc6qohuTK+9A4rdAwOnhd8T /lk/naGEyMprRPxaKS5y6D7TsZmqsgyCyE2CzroINsiEzeG2X7zEavx2UaetI/rhPxHY kMD5OAfJyKs3RCxh497TMFW2zMZZgaV9O8rfkYUOuBI496mfuNNk6/TD1mJjP2qbX3UF Ml4FSxXEPrUreMkbURy+8JUNS8JyZejcRHZBqnu+3SIpGLXYamTGEkEmygpkUPweu7CB JTtQ== X-Gm-Message-State: ALoCoQlkR67bt2/G6AivHHY+QwBEofkmz1HyCSe6ktaLT2Iq3Fd/2vOG4QwmrNkEj5jz4qVnc6NzEZcqmM/gnM6IQCQXuKMYvtF01LLQrnJ2Ii4InUiH339N4oSfQs7hzfCsxDyaK4pS+uTRzR0q5aMoUQVl9nolIw== X-Received: by 10.50.83.97 with SMTP id p1mr132840igy.41.1383696718600; Tue, 05 Nov 2013 16:11:58 -0800 (PST) X-Received: by 10.50.83.97 with SMTP id p1mr132832igy.41.1383696718415; Tue, 05 Nov 2013 16:11:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.245.233 with HTTP; Tue, 5 Nov 2013 16:11:28 -0800 (PST) In-Reply-To: <04942DC4-C5C4-431A-80C9-0EC855285430@cisco.com> References: <625DD549-A737-4A49-963C-A6AC503BBA11@mitre.org> <04942DC4-C5C4-431A-80C9-0EC855285430@cisco.com> From: Brian Campbell Date: Tue, 5 Nov 2013 16:11:28 -0800 Message-ID: To: "Matt Miller (mamille2)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] IETF WG Follow-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 00:12:23 -0000 Both after the plenary tomorrow and/or after JOSE on Thus work for me. Though not too much after as I've got other commitments later on both days. What about a "working lunch" tomorrow after the plenary? I bet even Matt eats lunch... On Tue, Nov 5, 2013 at 3:28 PM, Matt Miller (mamille2) wrote: > > On Nov 5, 2013, at 3:01 PM, Richer, Justin P. wrote: > >> At the end of Monday's WG session here at IETF, Derek suggested that sev= eral of us who are here ought to get together and hash out some detailed so= lutions to Dyn-Reg and related issues in person while we have the opportuni= ty. As such, I suggest that those of us who are interested get together eit= her tomorrow after the morning plenary session or on Thursday after the JOS= E session. I'm personally here for the remainder of the week so I'm open to= other concrete suggestions as well. >> >> I'm even willing to bring my laptop along and we can try doing live spec= surgery if it comes to that. >> > > I fully support this action, but unfortunately I'm not sure I personally = can participate before Friday afternoon. I'm not entirely sure how much be= nefit I can provide directly, but am more than willing to review the output= . > > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From mamille2@cisco.com Tue Nov 5 16:34:17 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB6921F9EB0 for ; Tue, 5 Nov 2013 16:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9qtFnYBf7Ki for ; Tue, 5 Nov 2013 16:34:12 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id BEB6921E80AF for ; Tue, 5 Nov 2013 16:34:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2979; q=dns/txt; s=iport; t=1383698051; x=1384907651; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4OFMnmEAxiUVN8GGVTjwQBVK/SbuPddE0rHRy/SyBBc=; b=BeUG2X7LJLMKpUH+Z0NmfNDWuw3YgjNpkwVj4z4rOfbUvsX3nHntad3b 0WxLOVSrKIi0AWtedf6MAkB7ZYXseTVs4H9xQ6eewP17M9VxvtQYokBze LAkJfI3VYl4j43BKbYLZiaQ65PO1+/8f5ButWzLGLd1qm4SMxq1TOY0Cx M=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAEOOeVKtJXG+/2dsb2JhbABZgwc4U79HgSYWdIIlAQEBAwEBAQFrCwULAgEIDgouJwslAgQOBQ4Nh2AGDb5jBI9ZB4MggQ8DkC6BMIYskgmDJoIq X-IronPort-AV: E=Sophos;i="4.93,642,1378857600"; d="asc'?scan'208";a="280979419" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 06 Nov 2013 00:34:11 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA60YAim000788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Nov 2013 00:34:10 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.19]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 18:34:10 -0600 From: "Matt Miller (mamille2)" To: Brian Campbell , "Richer, Justin P." Thread-Topic: [OAUTH-WG] IETF WG Follow-up Thread-Index: AQHO2nsHp2zTTchBW0Cml/XgPnOUX5oXrR4AgAAL+gCAAAZXgA== Date: Wed, 6 Nov 2013 00:34:10 +0000 Message-ID: <1681D5B1-A7C6-4CC5-9037-E44AFDAD8F4B@cisco.com> References: <625DD549-A737-4A49-963C-A6AC503BBA11@mitre.org> <04942DC4-C5C4-431A-80C9-0EC855285430@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.146.220] Content-Type: multipart/signed; boundary="Apple-Mail=_4D1464FE-83E4-49C7-9278-5FE9F41F1F3E"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] IETF WG Follow-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 00:34:17 -0000 --Apple-Mail=_4D1464FE-83E4-49C7-9278-5FE9F41F1F3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 A working lunch I can do in both cases, if real-time feedback is deemed = worthwhile. I could also participate in a dinner session Wednesday = night. Otherwise, I will review anything posted to the list of you can send me = pre-drafts. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On Nov 5, 2013, at 4:11 PM, Brian Campbell = wrote: > Both after the plenary tomorrow and/or after JOSE on Thus work for me. > Though not too much after as I've got other commitments later on both > days. >=20 > What about a "working lunch" tomorrow after the plenary? I bet even > Matt eats lunch... >=20 >=20 >=20 > On Tue, Nov 5, 2013 at 3:28 PM, Matt Miller (mamille2) > wrote: >>=20 >> On Nov 5, 2013, at 3:01 PM, Richer, Justin P. = wrote: >>=20 >>> At the end of Monday's WG session here at IETF, Derek suggested that = several of us who are here ought to get together and hash out some = detailed solutions to Dyn-Reg and related issues in person while we have = the opportunity. As such, I suggest that those of us who are interested = get together either tomorrow after the morning plenary session or on = Thursday after the JOSE session. I'm personally here for the remainder = of the week so I'm open to other concrete suggestions as well. >>>=20 >>> I'm even willing to bring my laptop along and we can try doing live = spec surgery if it comes to that. >>>=20 >>=20 >> I fully support this action, but unfortunately I'm not sure I = personally can participate before Friday afternoon. I'm not entirely = sure how much benefit I can provide directly, but am more than willing = to review the output. >>=20 >>=20 >> - m&m >>=20 >> Matt Miller < mamille2@cisco.com > >> Cisco Systems, Inc. >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 --Apple-Mail=_4D1464FE-83E4-49C7-9278-5FE9F41F1F3E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSeY6CAAoJEDWi+S0W7cO12rwH/0JyxaVea0MT+7q8JyxC1CqI vo1Rt8RuYM1RviRd2lqDbGkeHvu6+YPSiusl/GDr9WqXJD+IMBamjNNm9erVwmja tUGD+LIRDt+D8KPAhRcu16KapmTjewsJXJzi4dKOei8MVbvW6l3rapaG8Xf+PWws yKiC/hs5/NWJHos02Q24zeEJ9r5tKZqQLOCZjP/TgBJJjDMyXBQ5FYgxRBtMXDBL Rg4dcxoXtw/wggD3Id+rRNwHrX98amiL/U35RfamXuxZ5yqqg2nKseR9yDKHzsMP AQ3pdGiK4rkw9r8b5yrztKsbaYJ3JxkuYGjrDnMyjYBKj5cKOpEyk5ZOa2pRY/w= =VgKA -----END PGP SIGNATURE----- --Apple-Mail=_4D1464FE-83E4-49C7-9278-5FE9F41F1F3E-- From derek@ihtfp.com Tue Nov 5 16:39:48 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5224D11E8199 for ; Tue, 5 Nov 2013 16:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.839 X-Spam-Level: X-Spam-Status: No, score=-101.839 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiWhOtKTRxsc for ; Tue, 5 Nov 2013 16:39:44 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 4A95111E818C for ; Tue, 5 Nov 2013 16:39:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 0C51A260237; Tue, 5 Nov 2013 19:39:40 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 24858-08; Tue, 5 Nov 2013 19:39:38 -0500 (EST) Received: by mail2.ihtfp.org (Postfix, from userid 48) id BDAA82602BA; Tue, 5 Nov 2013 19:39:37 -0500 (EST) Received: from 31.133.180.131 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Tue, 5 Nov 2013 19:39:37 -0500 Message-ID: <754430dfb90cfd775d05bb2225a222dd.squirrel@mail2.ihtfp.org> In-Reply-To: <1681D5B1-A7C6-4CC5-9037-E44AFDAD8F4B@cisco.com> References: <625DD549-A737-4A49-963C-A6AC503BBA11@mitre.org> <04942DC4-C5C4-431A-80C9-0EC855285430@cisco.com> <1681D5B1-A7C6-4CC5-9037-E44AFDAD8F4B@cisco.com> Date: Tue, 5 Nov 2013 19:39:37 -0500 From: "Derek Atkins" To: "Matt Miller (mamille2)" User-Agent: SquirrelMail/1.4.22-2.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] IETF WG Follow-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 00:39:48 -0000 I realize it's short notice but a bunch of us are going to try to get together for dinner tonight (Tuesday), meeting at the Hotel Lobby (near the concierge desk) at 1845. -derek On Tue, November 5, 2013 7:34 pm, Matt Miller (mamille2) wrote: > A working lunch I can do in both cases, if real-time feedback is deemed > worthwhile. I could also participate in a dinner session Wednesday night. > > Otherwise, I will review anything posted to the list of you can send me > pre-drafts. > > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > On Nov 5, 2013, at 4:11 PM, Brian Campbell > wrote: > >> Both after the plenary tomorrow and/or after JOSE on Thus work for me. >> Though not too much after as I've got other commitments later on both >> days. >> >> What about a "working lunch" tomorrow after the plenary? I bet even >> Matt eats lunch... >> >> >> >> On Tue, Nov 5, 2013 at 3:28 PM, Matt Miller (mamille2) >> wrote: >>> >>> On Nov 5, 2013, at 3:01 PM, Richer, Justin P. >>> wrote: >>> >>>> At the end of Monday's WG session here at IETF, Derek suggested that >>>> several of us who are here ought to get together and hash out some >>>> detailed solutions to Dyn-Reg and related issues in person while we >>>> have the opportunity. As such, I suggest that those of us who are >>>> interested get together either tomorrow after the morning plenary >>>> session or on Thursday after the JOSE session. I'm personally here for >>>> the remainder of the week so I'm open to other concrete suggestions as >>>> well. >>>> >>>> I'm even willing to bring my laptop along and we can try doing live >>>> spec surgery if it comes to that. >>>> >>> >>> I fully support this action, but unfortunately I'm not sure I >>> personally can participate before Friday afternoon. I'm not entirely >>> sure how much benefit I can provide directly, but am more than willing >>> to review the output. >>> >>> >>> - m&m >>> >>> Matt Miller < mamille2@cisco.com > >>> Cisco Systems, Inc. >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From phil.hunt@oracle.com Tue Nov 5 17:36:17 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC57D21F9C7D for ; Tue, 5 Nov 2013 17:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mU7oLMHAiaji for ; Tue, 5 Nov 2013 17:35:58 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9E321E8166 for ; Tue, 5 Nov 2013 17:35:27 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA61ZQs5018828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Nov 2013 01:35:26 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA61ZOdq009615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Nov 2013 01:35:25 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA61ZOUm024700; Wed, 6 Nov 2013 01:35:24 GMT Received: from [25.68.205.180] (/24.114.27.182) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 05 Nov 2013 17:35:24 -0800 References: <625DD549-A737-4A49-963C-A6AC503BBA11@mitre.org> <04942DC4-C5C4-431A-80C9-0EC855285430@cisco.com> <1681D5B1-A7C6-4CC5-9037-E44AFDAD8F4B@cisco.com> <754430dfb90cfd775d05bb2225a222dd.squirrel@mail2.ihtfp.org> Mime-Version: 1.0 (1.0) In-Reply-To: <754430dfb90cfd775d05bb2225a222dd.squirrel@mail2.ihtfp.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <812C2F97-88BD-4150-88F9-059FCD5E86E2@oracle.com> X-Mailer: iPhone Mail (11B511) From: Phil Hunt Date: Tue, 5 Nov 2013 17:34:42 -0800 To: Derek Atkins X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] IETF WG Follow-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:36:17 -0000 I can make it. Phil > On Nov 5, 2013, at 16:39, Derek Atkins wrote: > > I realize it's short notice but a bunch of us are going to try to get > together for dinner tonight (Tuesday), meeting at the Hotel Lobby (near > the concierge desk) at 1845. > > -derek > >> On Tue, November 5, 2013 7:34 pm, Matt Miller (mamille2) wrote: >> A working lunch I can do in both cases, if real-time feedback is deemed >> worthwhile. I could also participate in a dinner session Wednesday night. >> >> Otherwise, I will review anything posted to the list of you can send me >> pre-drafts. >> >> >> - m&m >> >> Matt Miller < mamille2@cisco.com > >> Cisco Systems, Inc. >> >> On Nov 5, 2013, at 4:11 PM, Brian Campbell >> wrote: >> >>> Both after the plenary tomorrow and/or after JOSE on Thus work for me. >>> Though not too much after as I've got other commitments later on both >>> days. >>> >>> What about a "working lunch" tomorrow after the plenary? I bet even >>> Matt eats lunch... >>> >>> >>> >>> On Tue, Nov 5, 2013 at 3:28 PM, Matt Miller (mamille2) >>> wrote: >>>> >>>> On Nov 5, 2013, at 3:01 PM, Richer, Justin P. >>>> wrote: >>>> >>>>> At the end of Monday's WG session here at IETF, Derek suggested that >>>>> several of us who are here ought to get together and hash out some >>>>> detailed solutions to Dyn-Reg and related issues in person while we >>>>> have the opportunity. As such, I suggest that those of us who are >>>>> interested get together either tomorrow after the morning plenary >>>>> session or on Thursday after the JOSE session. I'm personally here for >>>>> the remainder of the week so I'm open to other concrete suggestions as >>>>> well. >>>>> >>>>> I'm even willing to bring my laptop along and we can try doing live >>>>> spec surgery if it comes to that. >>>> >>>> I fully support this action, but unfortunately I'm not sure I >>>> personally can participate before Friday afternoon. I'm not entirely >>>> sure how much benefit I can provide directly, but am more than willing >>>> to review the output. >>>> >>>> >>>> - m&m >>>> >>>> Matt Miller < mamille2@cisco.com > >>>> Cisco Systems, Inc. >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Tue Nov 5 17:45:36 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7608F21E8136 for ; Tue, 5 Nov 2013 17:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.373 X-Spam-Level: X-Spam-Status: No, score=-6.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MR7JbhB0l1oM for ; Tue, 5 Nov 2013 17:45:31 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B8FC011E81D6 for ; Tue, 5 Nov 2013 17:44:30 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4E9002260033; Tue, 5 Nov 2013 20:44:30 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2E324226000E; Tue, 5 Nov 2013 20:44:30 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.251]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0158.001; Tue, 5 Nov 2013 20:44:30 -0500 From: "Richer, Justin P." To: Phil Hunt Thread-Topic: [OAUTH-WG] IETF WG Follow-up Thread-Index: AQHO2pBdp2zTTchBW0Cml/XgPnOUX5oXwieA Date: Wed, 6 Nov 2013 01:44:28 +0000 Message-ID: <4D9E7679-1226-4EDF-9516-9D583FF2BB36@mitre.org> References: <625DD549-A737-4A49-963C-A6AC503BBA11@mitre.org> <04942DC4-C5C4-431A-80C9-0EC855285430@cisco.com> <1681D5B1-A7C6-4CC5-9037-E44AFDAD8F4B@cisco.com> <754430dfb90cfd775d05bb2225a222dd.squirrel@mail2.ihtfp.org> <812C2F97-88BD-4150-88F9-059FCD5E86E2@oracle.com> In-Reply-To: <812C2F97-88BD-4150-88F9-059FCD5E86E2@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.6.132] Content-Type: text/plain; charset="us-ascii" Content-ID: <80648167BA9DF04EBB188461C2B86CC5@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Derek Atkins , "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] IETF WG Follow-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:45:37 -0000 I'll be there as well. -- Justin On Nov 5, 2013, at 5:34 PM, Phil Hunt wrote: > I can make it.=20 >=20 > Phil >=20 >> On Nov 5, 2013, at 16:39, Derek Atkins wrote: >>=20 >> I realize it's short notice but a bunch of us are going to try to get >> together for dinner tonight (Tuesday), meeting at the Hotel Lobby (near >> the concierge desk) at 1845. >>=20 >> -derek >>=20 >>> On Tue, November 5, 2013 7:34 pm, Matt Miller (mamille2) wrote: >>> A working lunch I can do in both cases, if real-time feedback is deemed >>> worthwhile. I could also participate in a dinner session Wednesday nig= ht. >>>=20 >>> Otherwise, I will review anything posted to the list of you can send me >>> pre-drafts. >>>=20 >>>=20 >>> - m&m >>>=20 >>> Matt Miller < mamille2@cisco.com > >>> Cisco Systems, Inc. >>>=20 >>> On Nov 5, 2013, at 4:11 PM, Brian Campbell >>> wrote: >>>=20 >>>> Both after the plenary tomorrow and/or after JOSE on Thus work for me. >>>> Though not too much after as I've got other commitments later on both >>>> days. >>>>=20 >>>> What about a "working lunch" tomorrow after the plenary? I bet even >>>> Matt eats lunch... >>>>=20 >>>>=20 >>>>=20 >>>> On Tue, Nov 5, 2013 at 3:28 PM, Matt Miller (mamille2) >>>> wrote: >>>>>=20 >>>>> On Nov 5, 2013, at 3:01 PM, Richer, Justin P. >>>>> wrote: >>>>>=20 >>>>>> At the end of Monday's WG session here at IETF, Derek suggested that >>>>>> several of us who are here ought to get together and hash out some >>>>>> detailed solutions to Dyn-Reg and related issues in person while we >>>>>> have the opportunity. As such, I suggest that those of us who are >>>>>> interested get together either tomorrow after the morning plenary >>>>>> session or on Thursday after the JOSE session. I'm personally here f= or >>>>>> the remainder of the week so I'm open to other concrete suggestions = as >>>>>> well. >>>>>>=20 >>>>>> I'm even willing to bring my laptop along and we can try doing live >>>>>> spec surgery if it comes to that. >>>>>=20 >>>>> I fully support this action, but unfortunately I'm not sure I >>>>> personally can participate before Friday afternoon. I'm not entirely >>>>> sure how much benefit I can provide directly, but am more than willin= g >>>>> to review the output. >>>>>=20 >>>>>=20 >>>>> - m&m >>>>>=20 >>>>> Matt Miller < mamille2@cisco.com > >>>>> Cisco Systems, Inc. >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> --=20 >> Derek Atkins 617-623-3745 >> derek@ihtfp.com www.ihtfp.com >> Computer and Internet Security Consultant >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Tue Nov 5 17:47:44 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8649921F9E1D for ; Tue, 5 Nov 2013 17:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.051 X-Spam-Level: X-Spam-Status: No, score=0.051 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_PILL=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OETDZGUtVm-O for ; Tue, 5 Nov 2013 17:47:27 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by ietfa.amsl.com (Postfix) with ESMTP id BAA2B21F8FDC for ; Tue, 5 Nov 2013 17:47:07 -0800 (PST) Received: from [80.67.16.118] (helo=webmail.df.eu) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1VdsD4-0001o2-1n for oauth@ietf.org; Wed, 06 Nov 2013 02:47:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 05 Nov 2013 17:47:06 -0800 From: Torsten Lodderstedt To: oauth@ietf.org In-Reply-To: <4D9E7679-1226-4EDF-9516-9D583FF2BB36@mitre.org> References: <625DD549-A737-4A49-963C-A6AC503BBA11@mitre.org> <04942DC4-C5C4-431A-80C9-0EC855285430@cisco.com> <1681D5B1-A7C6-4CC5-9037-E44AFDAD8F4B@cisco.com> <754430dfb90cfd775d05bb2225a222dd.squirrel@mail2.ihtfp.org> <812C2F97-88BD-4150-88F9-059FCD5E86E2@oracle.com> <4D9E7679-1226-4EDF-9516-9D583FF2BB36@mitre.org> Message-ID: <8dad67f8007eb86db0787aff20efdeef@lodderstedt-online.de> X-Sender: torsten@lodderstedt.net User-Agent: Roundcube Webmail X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [OAUTH-WG] IETF WG Follow-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:47:44 -0000 me too Am 05.11.2013 17:44, schrieb Richer, Justin P.: > I'll be there as well. > > -- Justin > > On Nov 5, 2013, at 5:34 PM, Phil Hunt > wrote: > >> I can make it. >> >> Phil >> >>> On Nov 5, 2013, at 16:39, Derek Atkins wrote: >>> >>> I realize it's short notice but a bunch of us are going to try to get >>> together for dinner tonight (Tuesday), meeting at the Hotel Lobby >>> (near >>> the concierge desk) at 1845. >>> >>> -derek >>> >>>> On Tue, November 5, 2013 7:34 pm, Matt Miller (mamille2) wrote: >>>> A working lunch I can do in both cases, if real-time feedback is >>>> deemed >>>> worthwhile. I could also participate in a dinner session Wednesday >>>> night. >>>> >>>> Otherwise, I will review anything posted to the list of you can send >>>> me >>>> pre-drafts. >>>> >>>> >>>> - m&m >>>> >>>> Matt Miller < mamille2@cisco.com > >>>> Cisco Systems, Inc. >>>> >>>> On Nov 5, 2013, at 4:11 PM, Brian Campbell >>>> >>>> wrote: >>>> >>>>> Both after the plenary tomorrow and/or after JOSE on Thus work for >>>>> me. >>>>> Though not too much after as I've got other commitments later on >>>>> both >>>>> days. >>>>> >>>>> What about a "working lunch" tomorrow after the plenary? I bet even >>>>> Matt eats lunch... >>>>> >>>>> >>>>> >>>>> On Tue, Nov 5, 2013 at 3:28 PM, Matt Miller (mamille2) >>>>> wrote: >>>>>> >>>>>> On Nov 5, 2013, at 3:01 PM, Richer, Justin P. >>>>>> wrote: >>>>>> >>>>>>> At the end of Monday's WG session here at IETF, Derek suggested >>>>>>> that >>>>>>> several of us who are here ought to get together and hash out >>>>>>> some >>>>>>> detailed solutions to Dyn-Reg and related issues in person while >>>>>>> we >>>>>>> have the opportunity. As such, I suggest that those of us who are >>>>>>> interested get together either tomorrow after the morning plenary >>>>>>> session or on Thursday after the JOSE session. I'm personally >>>>>>> here for >>>>>>> the remainder of the week so I'm open to other concrete >>>>>>> suggestions as >>>>>>> well. >>>>>>> >>>>>>> I'm even willing to bring my laptop along and we can try doing >>>>>>> live >>>>>>> spec surgery if it comes to that. >>>>>> >>>>>> I fully support this action, but unfortunately I'm not sure I >>>>>> personally can participate before Friday afternoon. I'm not >>>>>> entirely >>>>>> sure how much benefit I can provide directly, but am more than >>>>>> willing >>>>>> to review the output. >>>>>> >>>>>> >>>>>> - m&m >>>>>> >>>>>> Matt Miller < mamille2@cisco.com > >>>>>> Cisco Systems, Inc. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> -- >>> Derek Atkins 617-623-3745 >>> derek@ihtfp.com www.ihtfp.com >>> Computer and Internet Security Consultant >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From sakimura@gmail.com Tue Nov 5 17:54:31 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4043511E811A for ; Tue, 5 Nov 2013 17:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.539 X-Spam-Level: X-Spam-Status: No, score=-1.539 tagged_above=-999 required=5 tests=[AWL=-0.606, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfU1qqws6LSC for ; Tue, 5 Nov 2013 17:54:30 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 709CB21F9D9C for ; Tue, 5 Nov 2013 17:54:22 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id el20so1177883lab.5 for ; Tue, 05 Nov 2013 17:54:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=evMIooXlYLEJ1ZkuU213sjB96QBf0W7V5EreGLMWNv8=; b=lklbHGe2Qy9Q/BwCi4fuj9KfiXkjRr23XLSsRFj1an94YreLs4cESsB7iSBeOdxQjx DBuPVNt7/ztq7kKvO4NdxilGMgannWFJtnVjxPy3yh93DykV6CHtMfRqXZKXaGcoXwjb 33EKqLBAgk84ZRxRhZJQn3usGLE9rhEHrSXHRvjMPrtN3K07kTaEkzFq+AAwhRVpTj2U Y/NPxGwb0e7Lqu14hISCwKc5pbajlIunzz9aYy5k7FQ+o+OnV3NYs3E/LGi4NprSQYog /jr2lsEKgqCiq1skMznLxtMUVWgWw1E3T9ad2KByoBuQbIkKrrisL+9+GG4VgfOexf9H VROg== MIME-Version: 1.0 X-Received: by 10.112.200.170 with SMTP id jt10mr850752lbc.10.1383702861252; Tue, 05 Nov 2013 17:54:21 -0800 (PST) Received: by 10.112.134.38 with HTTP; Tue, 5 Nov 2013 17:54:21 -0800 (PST) In-Reply-To: <8dad67f8007eb86db0787aff20efdeef@lodderstedt-online.de> References: <625DD549-A737-4A49-963C-A6AC503BBA11@mitre.org> <04942DC4-C5C4-431A-80C9-0EC855285430@cisco.com> <1681D5B1-A7C6-4CC5-9037-E44AFDAD8F4B@cisco.com> <754430dfb90cfd775d05bb2225a222dd.squirrel@mail2.ihtfp.org> <812C2F97-88BD-4150-88F9-059FCD5E86E2@oracle.com> <4D9E7679-1226-4EDF-9516-9D583FF2BB36@mitre.org> <8dad67f8007eb86db0787aff20efdeef@lodderstedt-online.de> Date: Tue, 5 Nov 2013 17:54:21 -0800 Message-ID: From: Nat Sakimura To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=001a11c265b8850f1604ea786d41 Cc: oauth Subject: Re: [OAUTH-WG] IETF WG Follow-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:54:32 -0000 --001a11c265b8850f1604ea786d41 Content-Type: text/plain; charset=ISO-8859-1 I will show up as well. 2013/11/5 Torsten Lodderstedt > me too > > Am 05.11.2013 17:44, schrieb Richer, Justin P.: > > I'll be there as well. >> >> -- Justin >> >> On Nov 5, 2013, at 5:34 PM, Phil Hunt >> wrote: >> >> I can make it. >>> >>> Phil >>> >>> On Nov 5, 2013, at 16:39, Derek Atkins wrote: >>>> >>>> I realize it's short notice but a bunch of us are going to try to get >>>> together for dinner tonight (Tuesday), meeting at the Hotel Lobby (near >>>> the concierge desk) at 1845. >>>> >>>> -derek >>>> >>>> On Tue, November 5, 2013 7:34 pm, Matt Miller (mamille2) wrote: >>>>> A working lunch I can do in both cases, if real-time feedback is deemed >>>>> worthwhile. I could also participate in a dinner session Wednesday >>>>> night. >>>>> >>>>> Otherwise, I will review anything posted to the list of you can send me >>>>> pre-drafts. >>>>> >>>>> >>>>> - m&m >>>>> >>>>> Matt Miller < mamille2@cisco.com > >>>>> Cisco Systems, Inc. >>>>> >>>>> On Nov 5, 2013, at 4:11 PM, Brian Campbell >>>> > >>>>> wrote: >>>>> >>>>> Both after the plenary tomorrow and/or after JOSE on Thus work for me. >>>>>> Though not too much after as I've got other commitments later on both >>>>>> days. >>>>>> >>>>>> What about a "working lunch" tomorrow after the plenary? I bet even >>>>>> Matt eats lunch... >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Nov 5, 2013 at 3:28 PM, Matt Miller (mamille2) >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> On Nov 5, 2013, at 3:01 PM, Richer, Justin P. >>>>>>> wrote: >>>>>>> >>>>>>> At the end of Monday's WG session here at IETF, Derek suggested that >>>>>>>> several of us who are here ought to get together and hash out some >>>>>>>> detailed solutions to Dyn-Reg and related issues in person while we >>>>>>>> have the opportunity. As such, I suggest that those of us who are >>>>>>>> interested get together either tomorrow after the morning plenary >>>>>>>> session or on Thursday after the JOSE session. I'm personally here >>>>>>>> for >>>>>>>> the remainder of the week so I'm open to other concrete suggestions >>>>>>>> as >>>>>>>> well. >>>>>>>> >>>>>>>> I'm even willing to bring my laptop along and we can try doing live >>>>>>>> spec surgery if it comes to that. >>>>>>>> >>>>>>> >>>>>>> I fully support this action, but unfortunately I'm not sure I >>>>>>> personally can participate before Friday afternoon. I'm not entirely >>>>>>> sure how much benefit I can provide directly, but am more than >>>>>>> willing >>>>>>> to review the output. >>>>>>> >>>>>>> >>>>>>> - m&m >>>>>>> >>>>>>> Matt Miller < mamille2@cisco.com > >>>>>>> Cisco Systems, Inc. >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>>> >>>> -- >>>> Derek Atkins 617-623-3745 >>>> derek@ihtfp.com www.ihtfp.com >>>> Computer and Internet Security Consultant >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c265b8850f1604ea786d41 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I will show up as well.=A0


2013/11/5 Torsten Lodderstedt <t= orsten@lodderstedt.net>
me too

Am 05.11.2013 17:44, schrieb Richer, Justin P.:

I'll be there as well.

=A0-- Justin

On Nov 5, 2013, at 5:34 PM, Phil Hunt <phil.hunt@oracle.com>
=A0wrote:

I can make it.

Phil

On Nov 5, 2013, at 16:39, Derek Atkins <derek@ihtfp.com> wrote:

I realize it's short notice but a bunch of us are going to try to get together for dinner tonight (Tuesday), meeting at the Hotel Lobby (near
the concierge desk) at 1845.

-derek

On Tue, November 5, 2013 7:34 pm, Matt Miller (mamille2) wrote:
A working lunch I can do in both cases, if real-time feedback is deemed
worthwhile. =A0I could also participate in a dinner session Wednesday night= .

Otherwise, I will review anything posted to the list of you can send me
pre-drafts.


- m&m

Matt Miller < ma= mille2@cisco.com >
Cisco Systems, Inc.

On Nov 5, 2013, at 4:11 PM, Brian Campbell <bcampbell@pingidentity.com>
wrote:

Both after the plenary tomorrow and/or after JOSE on Thus work for me.
Though not too much after as I've got other commitments later on both days.

What about a "working lunch" tomorrow after the plenary? I bet ev= en
Matt eats lunch...



On Tue, Nov 5, 2013 at 3:28 PM, Matt Miller (mamille2)
<mamille2@cisco.= com> wrote:

On Nov 5, 2013, at 3:01 PM, Richer, Justin P. <jricher@mitre.org>
wrote:

At the end of Monday's WG session here at IETF, Derek suggested that several of us who are here ought to get together and hash out some
detailed solutions to Dyn-Reg and related issues in person while we
have the opportunity. As such, I suggest that those of us who are
interested get together either tomorrow after the morning plenary
session or on Thursday after the JOSE session. I'm personally here for<= br> the remainder of the week so I'm open to other concrete suggestions as<= br> well.

I'm even willing to bring my laptop along and we can try doing live
spec surgery if it comes to that.

I fully support this action, but unfortunately I'm not sure I
personally can participate before Friday afternoon. =A0I'm not entirely=
sure how much benefit I can provide directly, but am more than willing
to review the output.


- m&m

Matt Miller < ma= mille2@cisco.com >
Cisco Systems, Inc.


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--
=A0 =A0 =A0Derek Atkins =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 617-623-3745
=A0 =A0 =A0derek@ihtfp= .com =A0 =A0 =A0 =A0 =A0 =A0 www.ihtfp.com
=A0 =A0 =A0Computer and Internet Security Consultant

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en
--001a11c265b8850f1604ea786d41-- From bcampbell@pingidentity.com Tue Nov 5 18:34:47 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2417311E8163 for ; Tue, 5 Nov 2013 18:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.941 X-Spam-Level: X-Spam-Status: No, score=-5.941 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6pxjeUAV7Kf for ; Tue, 5 Nov 2013 18:34:43 -0800 (PST) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by ietfa.amsl.com (Postfix) with ESMTP id E826821E80DE for ; Tue, 5 Nov 2013 18:34:40 -0800 (PST) Received: from mail-ie0-f170.google.com ([209.85.223.170]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKUnmqu2otdNZUMHZ48nzg1EpuINbzRtcH@postini.com; Tue, 05 Nov 2013 18:34:41 PST Received: by mail-ie0-f170.google.com with SMTP id at1so16999210iec.29 for ; Tue, 05 Nov 2013 18:34:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZARv3M3aY/lmSLk+nqCXz1hBVNv2uXLZT1b0DXsPUNM=; b=HK6ltPPB8ykZzy5coytrzA9ieLZDK24MZxl71OuRvgITbiTjQdjBk9WFzVjj8tRpF6 DzIQcBRrnMCikBngVInEHvhvrE5//b2/x2XPQp2X2a07tlRojz/+Hw62bpTSUvxOx2SP poyGxH1ha+E2gk1e3qDGxvgYLOjbarvxHskOn9imVlNxsmlOCcoHMqlA3cDs+uRAuWkr H2XiSz0GU7pjZMQtQ7sNhCctHqRob/ZX7OZ+Pr3rWNTh3P2ZHS0MRamv01VXvOejngRO AUQpipknldfkq23QGwhGOzoxum66HRn0w8bYUnuZs01kzBXNWS4fmQiTgMAvb1NKvETx RxZg== X-Gm-Message-State: ALoCoQnFfiI+r8hXKNJhT9LDXquVicPUaZ9ktikIUNrzovzBofUQAQLIdnpJQ+G8uRnlA79Nlc/vkvb1q5lwDMEopZTJAE2Ee5rFi4BcrN6YeSo3eKjqn2QS2itNc+T2a+m5sHdnGov4qq7U9YKCRxDH/sEG/c4MqA== X-Received: by 10.50.83.97 with SMTP id p1mr513606igy.41.1383705260225; Tue, 05 Nov 2013 18:34:20 -0800 (PST) X-Received: by 10.50.83.97 with SMTP id p1mr513598igy.41.1383705259992; Tue, 05 Nov 2013 18:34:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.245.233 with HTTP; Tue, 5 Nov 2013 18:33:49 -0800 (PST) In-Reply-To: References: <625DD549-A737-4A49-963C-A6AC503BBA11@mitre.org> <04942DC4-C5C4-431A-80C9-0EC855285430@cisco.com> <1681D5B1-A7C6-4CC5-9037-E44AFDAD8F4B@cisco.com> <754430dfb90cfd775d05bb2225a222dd.squirrel@mail2.ihtfp.org> <812C2F97-88BD-4150-88F9-059FCD5E86E2@oracle.com> <4D9E7679-1226-4EDF-9516-9D583FF2BB36@mitre.org> <8dad67f8007eb86db0787aff20efdeef@lodderstedt-online.de> From: Brian Campbell Date: Tue, 5 Nov 2013 18:33:49 -0800 Message-ID: To: Nat Sakimura Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth Subject: Re: [OAUTH-WG] IETF WG Follow-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 02:34:47 -0000 me too, me too On Tue, Nov 5, 2013 at 5:54 PM, Nat Sakimura wrote: > I will show up as well. > > > 2013/11/5 Torsten Lodderstedt >> >> me too >> >> Am 05.11.2013 17:44, schrieb Richer, Justin P.: >> >>> I'll be there as well. >>> >>> -- Justin >>> >>> On Nov 5, 2013, at 5:34 PM, Phil Hunt >>> wrote: >>> >>>> I can make it. >>>> >>>> Phil >>>> >>>>> On Nov 5, 2013, at 16:39, Derek Atkins wrote: >>>>> >>>>> I realize it's short notice but a bunch of us are going to try to get >>>>> together for dinner tonight (Tuesday), meeting at the Hotel Lobby (near >>>>> the concierge desk) at 1845. >>>>> >>>>> -derek >>>>> >>>>>> On Tue, November 5, 2013 7:34 pm, Matt Miller (mamille2) wrote: >>>>>> A working lunch I can do in both cases, if real-time feedback is >>>>>> deemed >>>>>> worthwhile. I could also participate in a dinner session Wednesday >>>>>> night. >>>>>> >>>>>> Otherwise, I will review anything posted to the list of you can send >>>>>> me >>>>>> pre-drafts. >>>>>> >>>>>> >>>>>> - m&m >>>>>> >>>>>> Matt Miller < mamille2@cisco.com > >>>>>> Cisco Systems, Inc. >>>>>> >>>>>> On Nov 5, 2013, at 4:11 PM, Brian Campbell >>>>>> >>>>>> wrote: >>>>>> >>>>>>> Both after the plenary tomorrow and/or after JOSE on Thus work for >>>>>>> me. >>>>>>> Though not too much after as I've got other commitments later on both >>>>>>> days. >>>>>>> >>>>>>> What about a "working lunch" tomorrow after the plenary? I bet even >>>>>>> Matt eats lunch... >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Nov 5, 2013 at 3:28 PM, Matt Miller (mamille2) >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> On Nov 5, 2013, at 3:01 PM, Richer, Justin P. >>>>>>>> wrote: >>>>>>>> >>>>>>>>> At the end of Monday's WG session here at IETF, Derek suggested >>>>>>>>> that >>>>>>>>> several of us who are here ought to get together and hash out some >>>>>>>>> detailed solutions to Dyn-Reg and related issues in person while we >>>>>>>>> have the opportunity. As such, I suggest that those of us who are >>>>>>>>> interested get together either tomorrow after the morning plenary >>>>>>>>> session or on Thursday after the JOSE session. I'm personally here >>>>>>>>> for >>>>>>>>> the remainder of the week so I'm open to other concrete suggestions >>>>>>>>> as >>>>>>>>> well. >>>>>>>>> >>>>>>>>> I'm even willing to bring my laptop along and we can try doing live >>>>>>>>> spec surgery if it comes to that. >>>>>>>> >>>>>>>> >>>>>>>> I fully support this action, but unfortunately I'm not sure I >>>>>>>> personally can participate before Friday afternoon. I'm not >>>>>>>> entirely >>>>>>>> sure how much benefit I can provide directly, but am more than >>>>>>>> willing >>>>>>>> to review the output. >>>>>>>> >>>>>>>> >>>>>>>> - m&m >>>>>>>> >>>>>>>> Matt Miller < mamille2@cisco.com > >>>>>>>> Cisco Systems, Inc. >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> -- >>>>> Derek Atkins 617-623-3745 >>>>> derek@ihtfp.com www.ihtfp.com >>>>> Computer and Internet Security Consultant >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From ve7jtb@ve7jtb.com Tue Nov 5 18:58:33 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802F021F9FFF for ; Tue, 5 Nov 2013 18:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-WW8JROtBEF for ; Tue, 5 Nov 2013 18:58:26 -0800 (PST) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCEF21E808F for ; Tue, 5 Nov 2013 18:58:25 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id ld10so9783787pab.24 for ; Tue, 05 Nov 2013 18:58:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:content-transfer-encoding:subject :references:from:mime-version:in-reply-to:message-id:date:cc:to; bh=tJs+GRiAO7rCFLwqI8aBU4Ir3IQzY1WKZoJu2BRtXwQ=; b=eAAKR05wxdcXseh7UZrWHGKMtWSyhc7v3Ky/zMtKRlw80gyfVhlF2ibE1fPdEzGQra dryGMK0c64VI15cOPy8Ux9nXQzIODfnSTib3IewiZ20yxwLcG6eRXRCQuLWHo5HicrcX SU+3ZFPNTNiBA1D/vVFma9RmQwzPF6WW4J9jr2LhM8GR7IZRB8we5lRrF6UcE0ocSbPL QhQxBY5HKFd452HjxqWIHQD4tw1etWs3h3DP+5zVkEXOYIZf/H0q4LCxHZH5nLSKPCWa SFcjTY7xLKnSY7fCFkFc9UMp7XOeQQtMS/0DbzdRXi8zZU62yIUN2iPvVYw64a3fNxK8 sOrA== X-Gm-Message-State: ALoCoQncG0kSUbxl+BUSs04xomirnI0HBfjSo4MW0OlE0Yxhk3FJJA2ivuPSNZac+Svo0B3oxg+v X-Received: by 10.66.51.34 with SMTP id h2mr1437733pao.181.1383706704603; Tue, 05 Nov 2013 18:58:24 -0800 (PST) Received: from [192.168.6.28] (199-91-80-194.ip.van.radiant.net. [199.91.80.194]) by mx.google.com with ESMTPSA id ed3sm37796662pbc.6.2013.11.05.18.58.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 18:58:23 -0800 (PST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable References: <625DD549-A737-4A49-963C-A6AC503BBA11@mitre.org> <04942DC4-C5C4-431A-80C9-0EC855285430@cisco.com> From: John Bradley Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: <30A7FC35-B009-4728-AC5A-061ACC7DFD75@ve7jtb.com> Date: Tue, 5 Nov 2013 18:42:59 -0800 To: Brian Campbell X-Mailer: iPhone Mail (11B511) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] IETF WG Follow-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 02:58:33 -0000 Both times work for me.=20 Sent from my iPhone > On Nov 5, 2013, at 4:11 PM, Brian Campbell wr= ote: >=20 > Both after the plenary tomorrow and/or after JOSE on Thus work for me. > Though not too much after as I've got other commitments later on both > days. >=20 > What about a "working lunch" tomorrow after the plenary? I bet even > Matt eats lunch... >=20 >=20 >=20 > On Tue, Nov 5, 2013 at 3:28 PM, Matt Miller (mamille2) > wrote: >>=20 >>> On Nov 5, 2013, at 3:01 PM, Richer, Justin P. wrote:= >>>=20 >>> At the end of Monday's WG session here at IETF, Derek suggested that sev= eral of us who are here ought to get together and hash out some detailed sol= utions to Dyn-Reg and related issues in person while we have the opportunity= . As such, I suggest that those of us who are interested get together either= tomorrow after the morning plenary session or on Thursday after the JOSE se= ssion. I'm personally here for the remainder of the week so I'm open to othe= r concrete suggestions as well. >>>=20 >>> I'm even willing to bring my laptop along and we can try doing live spec= surgery if it comes to that. >>=20 >> I fully support this action, but unfortunately I'm not sure I personally c= an participate before Friday afternoon. I'm not entirely sure how much bene= fit I can provide directly, but am more than willing to review the output. >>=20 >>=20 >> - m&m >>=20 >> Matt Miller < mamille2@cisco.com > >> Cisco Systems, Inc. >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From cmortimore@salesforce.com Tue Nov 5 21:19:30 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC17A21E80B5 for ; Tue, 5 Nov 2013 21:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oV8FMRcqK1aN for ; Tue, 5 Nov 2013 21:19:26 -0800 (PST) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAC721E80BF for ; Tue, 5 Nov 2013 21:19:23 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id wn1so9643757obc.16 for ; Tue, 05 Nov 2013 21:19:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XN9IaOZDTqba6VD+PVUb7dHt2sO4EvTQRqrViWliLwA=; b=JQDxJuJL6CoCiQ6Jrza0JqT1qP56qPF79URjRK3h1HqnPIwW9wzNnvI528bbJ0C6lv 7fDJJl7Q+d0SV+N3aldk/6OU7MdCLjCwm1AuX3sbB6hj1reTwB4ff7g0GCOclLD1wU3P WL+9TmPoLGSHGXzsoDkLvzoNeHcrtS5TpdevBSl/ZKIHsc3rEdBS1CfQ+qX6SUGiqYDD 2dx9l/W4ytwdcoZmJ1wlEYxLqKsTcHM/vieVryLfGAi8KCQSm+MPh/64Cb/tUn+sB14c TfVM5Hd2buRAFN79ObJ6a7JGlyR71Wz/Phn8p7u7qDPupSsGVIpYNYsL7Y7IYpHz7cAy DHTQ== X-Gm-Message-State: ALoCoQk184HZi4KvpZbEPAOOtwNuDPK+yIGmPoCB2ILsycQOhU/kZgGD7ko9TrhU8VCxV5/2USSr MIME-Version: 1.0 X-Received: by 10.60.44.178 with SMTP id f18mr1097845oem.43.1383715163280; Tue, 05 Nov 2013 21:19:23 -0800 (PST) Received: by 10.76.24.162 with HTTP; Tue, 5 Nov 2013 21:19:23 -0800 (PST) In-Reply-To: References: Date: Tue, 5 Nov 2013 21:19:23 -0800 Message-ID: From: Chuck Mortimore To: Brian Campbell Content-Type: multipart/alternative; boundary=001a11333a4ec7209404ea7b4abb Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] audience (was draft-ietf-oauth-saml2-bearer-17) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 05:19:31 -0000 --001a11333a4ec7209404ea7b4abb Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 4, 2013 at 11:58 AM, Brian Campbell wrote: > On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig > wrote > > Item #2: You wrote: > > > > " > > Section 2.5.1.4 of Assertions and Protocols for the OASIS > > Security Assertion Markup Language [OASIS.saml-core-2.0-os] > > defines the and elements and, > > in addition to the URI references discussed there, the token > > endpoint URL of the authorization server MAY be used as a URI > > that identifies the authorization server as an intended > > audience. Assertions that do not identify the Authorization > > Server as an intended audience MUST be rejected. > > " > > > > The 'MAY' is extremely weak here. If you make it a MUST that there has > to be > > the endpoint URL of the authorization server in there then that would > > provide so much more interoperability. As a reader I wouldn't know what > > other options I have and systems that provision necessary databases / > tables > > to ensure that the comparison takes place will also struggle. > > The "MAY" is intended to be weak and is only a suggestion for > deployments which don't already have a suitable identifier (like a > SAML 2 entity ID) for an audience value. > > I understand that you'd like this to be tighter but the suggestion is > not viable and it wouldn't provide the perceived interoperability > panacea anyway. Some information needs to be agreed upon for this to > work. How is out of scope here. The audience is one such value. Even > if mandating one specific thing for audience was feasible, it wouldn't > add to interoperability because there is other information that has to > be agreed on anyway. > > > > Then, there is again this SHOULD regarding the comparison operation, see > > " > > Audience > > values SHOULD be compared using the Simple String Comparison > > method defined in Section 6.2.1 of RFC 3986 [RFC3986], unless > > otherwise specified by the application. > > " > > > > I would replace it with a MUST, as I argued in > > draft-ietf-oauth-jwt-bearer-06. > > As I said there [1], I think I'm okay with that but would like to hear > from others in the WG. > I'm ok with that as well. > > [1] http://www.ietf.org/mail-archive/web/oauth/current/msg12251.html > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11333a4ec7209404ea7b4abb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Nov 4, 2013 at 11:58 AM, Brian Campbell &= lt;bcampbel= l@pingidentity.com> wrote:
On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tscho= fenig
<hannes.tschofenig@gmx.net<= /a>> wrote
> Item #2: You wrote:
>
> "
> Section 2.5.1.4 of Assertions and Protocols for the OASIS
> =A0 =A0 =A0 =A0 Security Assertion Markup Language [OASIS.saml-core-2.= 0-os]
> =A0 =A0 =A0 =A0 defines the <AudienceRestriction> and <Audien= ce> elements and,
> =A0 =A0 =A0 =A0 in addition to the URI references discussed there, the= token
> =A0 =A0 =A0 =A0 endpoint URL of the authorization server MAY be used a= s a URI
> =A0 =A0 =A0 =A0 that identifies the authorization server as an intende= d
> =A0 =A0 =A0 =A0 audience. =A0Assertions that do not identify the Autho= rization
> =A0 =A0 =A0 =A0 Server as an intended audience MUST be rejected.
> "
>
> The 'MAY' is extremely weak here. If you make it a MUST that t= here has to be
> the endpoint URL of the authorization server in there then that would<= br> > provide so much more interoperability. As a reader I wouldn't know= what
> other options I have and systems that provision necessary databases / = tables
> to ensure that the comparison takes place will also struggle.

The "MAY" is intended to be weak and is only a suggestion for
deployments which don't already have a suitable identifier (like a
SAML 2 entity ID) for an audience value.

I understand that you'd like this to be tighter but the suggestion is not viable and it wouldn't provide the perceived interoperability
panacea anyway. Some information needs to be agreed upon for this to
work. How is out of scope here. The audience is one such value. Even
if mandating one specific thing for audience was feasible, it wouldn't<= br> add to interoperability because there is other information that has to
be agreed on anyway.


> Then, there is again this SHOULD regarding the comparison operation, s= ee
> "
> =A0Audience
> =A0 =A0 =A0 =A0 values SHOULD be compared using the Simple String Comp= arison
> =A0 =A0 =A0 =A0 method defined in Section 6.2.1 of RFC 3986 [RFC3986],= unless
> =A0 =A0 =A0 =A0 otherwise specified by the application.
> "
>
> I would replace it with a MUST, as I argued in
> draft-ietf-oauth-jwt-bearer-06.

As I said there [1], I think I'm okay with that but would like to hear<= br> from others in the WG.



[1] http://www.ietf.org/mail-archive/web/oauth/current/= msg12251.html
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--001a11333a4ec7209404ea7b4abb-- From cmortimore@salesforce.com Tue Nov 5 21:21:22 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117DA21E80AE for ; Tue, 5 Nov 2013 21:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbugthYqQkA0 for ; Tue, 5 Nov 2013 21:21:17 -0800 (PST) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id C463121E80B5 for ; Tue, 5 Nov 2013 21:21:17 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id k1so1656485oag.20 for ; Tue, 05 Nov 2013 21:21:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oiOcgGuyGVqJN0Q5/AVJmyzbk8I2bORh2pPwCE/LRAk=; b=dgLfq7jZb/MbZrwf6sLGVpqVxQdNVg5WLp5vDmb455Sam7ictwzLQ1BrCMro1iNF7i h1OmZO/0v2tvlD/6n+ff8VU9SOGCoxs5Gc5grDX2Qbb6bRXA5tf5rtVTy/j61jxSzxzm CnAQkaxmAdeo/sUkCCffJZQuKMnQpj6MOYf3VFhst6S/Erkscx3VFvOkUat4B64UrSBR toNQZ/rMi4R36BwtHEljL+Q/REJHc9oCp8QXLXNz9ys5VBjR4rdMlKOy0PLlnNzFGJeh PNzPdAdKxro4n75Sd8dq14//uJhZAXEiJt84wwAnSbR49d7uh4jUSxqNNfPHKt44Gkcx IBTg== X-Gm-Message-State: ALoCoQmzoPM1C6qYx9nf/aWbf29/e1dm25f/W+seka/X0t3UTkfGKfOoxClwwwkqPwBTf9miXP2L MIME-Version: 1.0 X-Received: by 10.182.40.201 with SMTP id z9mr1112269obk.45.1383715277283; Tue, 05 Nov 2013 21:21:17 -0800 (PST) Received: by 10.76.24.162 with HTTP; Tue, 5 Nov 2013 21:21:17 -0800 (PST) In-Reply-To: References: Date: Tue, 5 Nov 2013 21:21:17 -0800 Message-ID: From: Chuck Mortimore To: Brian Campbell Content-Type: multipart/alternative; boundary=001a11c33b0292b6cc04ea7b51a3 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] audience (was draft-ietf-oauth-jwt-bearer-06) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 05:21:22 -0000 --001a11c33b0292b6cc04ea7b51a3 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 4, 2013 at 10:45 AM, Brian Campbell wrote: > On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig > wrote: > > You write: > > > > " > > 3. The JWT MUST contain an "aud" (audience) claim containing a > > value that identifies the authorization server as an intended > > audience. The token endpoint URL of the authorization server > > MAY be used as a value for an "aud" element to identify the > > authorization server as an intended audience of the JWT. JWTs > > that do not identify the authorization server as an intended > > audience MUST be rejected.... > > " > > > > If the endpoint URL of the AS is not used then what else? Wouldn't it be > > useful to say "The token endpoint URL of the authorization server > > MUST be used as a value for an "aud" element to identify the > > authorization server as an intended audience of the JWT."? > > This and the other assertion documents offer the token endpoint URL as > one way to identify the AS for deployments which lack some other means > of doing so. However, these assertion profiles are little slices of > functionality that augment existing deployments of OAuth, often in > conjunction with other 'federated' technologies for which there will > be an existing and agreed upon identifier that the issuer is known by. > This is not just academic - it's how these systems and deployment > already work. It's inappropriate and unrealistic for this document (or > the other assertion docs) to preclude common and useful deployment > practices. > Agreed. > > > Then, I have a suggestion for re-phrasing this sentence from : > > " > > Audience values SHOULD be compared > > using the Simple String Comparison method defined in Section > > 6.2.1 of RFC 3986 [RFC3986], unless otherwise specified by the > > application. > > " > > to: > > > > " > > In the absence of an application profile standard specifying > > otherwise, a compliant JWT Bearer application MUST compare the audience > > values using the Simple String Comparison method defined in Section > > 6.2.1 of RFC 3986 [RFC3986]. > > " > > I think I'm okay with that re-phrasing. Do others (my co-authors > especially) agree? Or object? > I'm good with it. -cmort > > > > > The same can actually be applied to the issuer claim as well. > > As I said in the previous mail about issuer, I'd like to get rid of > the comparison text. However, if such text stays, I'll work to make it > consistent throughout. > > > Given that the JWT had been updated to align it with the JOSE work I > suspect > > that this document also requires an update. > > You may well be correct. But despite following the JOSE and JWT work, > I'm not sure I know what update(s) would be required. Can you > elaborate? > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11c33b0292b6cc04ea7b51a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Mon, Nov 4, 2013 at 10:45 AM, Brian Campbell <bcampbell@pingid= entity.com> wrote:
On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tscho= fenig
<hannes.tschofenig@gmx.net<= /a>> wrote:
> You write:
>
> "
> =A03. =A0 The JWT MUST contain an "aud" (audience) claim con= taining a
> =A0 =A0 =A0 =A0 value that identifies the authorization server as an i= ntended
> =A0 =A0 =A0 =A0 audience. =A0The token endpoint URL of the authorizati= on server
> =A0 =A0 =A0 =A0 MAY be used as a value for an "aud" element = to identify the
> =A0 =A0 =A0 =A0 authorization server as an intended audience of the JW= T. =A0JWTs
> =A0 =A0 =A0 =A0 that do not identify the authorization server as an in= tended
> =A0 =A0 =A0 =A0 audience MUST be rejected....
> "
>
> If the endpoint URL of the AS is not used then what else? Wouldn't= it be
> useful to say "The token endpoint URL of the authorization server=
> =A0 =A0 =A0 =A0 MUST be used as a value for an "aud" element= to identify the
> =A0 =A0 =A0 =A0 authorization server as an intended audience of the JW= T."?

This and the other assertion documents offer the token endpoint URL as
one way to identify the AS for deployments which lack some other means
of doing so. However, these assertion profiles are little slices of
functionality that augment existing deployments of OAuth, often in
conjunction with other 'federated' technologies for which there wil= l
be an existing and agreed upon identifier that the issuer is known by.
This is not just academic - it's how these systems and deployment
already work. It's inappropriate and unrealistic for this document (or<= br> the other assertion docs) to preclude common and useful deployment
practices.

=A0

> Then, I have a suggestion for re-phrasing this sentence from :
> "
> =A0 =A0 =A0 =A0 Audience values SHOULD be compared
> =A0 =A0 =A0 =A0 using the Simple String Comparison method defined in S= ection
> =A0 =A0 =A0 =A0 6.2.1 of RFC 3986 [RFC3986], unless otherwise specifie= d by the
> =A0 =A0 =A0 =A0 application.
> "
> to:
>
> "
> In the absence of an application profile standard specifying
> otherwise, a compliant JWT Bearer application MUST compare the audienc= e
> values using the Simple String Comparison method defined in Section > =A0 =A0 =A0 =A0 6.2.1 of RFC 3986 [RFC3986].
> "

I think I'm okay with that re-phrasing. Do others (my co-authors
especially) agree? Or object?

I'm g= ood with it.

-cmort


--001a11c33b0292b6cc04ea7b51a3-- From sakimura@gmail.com Wed Nov 6 11:10:45 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279E421E80B6 for ; Wed, 6 Nov 2013 11:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzvUHxPvadJz for ; Wed, 6 Nov 2013 11:10:44 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id A03FF21F9CC2 for ; Wed, 6 Nov 2013 11:10:43 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id y6so81954lbh.11 for ; Wed, 06 Nov 2013 11:10:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y9MUqJy9pQfTm9uJ4A0T2w7hDge4CFxSUAhWpoGJKMI=; b=YfcgUU2iwPTRt6JBhRQNs+E2+Au+ILcprid79OXknqR8pQVTMyjr/nHHeUs5/VL0Ez uS+5w37UUCimsRpUbWhaVvT4RLvffJ4oPWqOq0CN1NLkQZU48tGIXUYk51HRIkbMsQFV 2ThosoUC7pQj3VKYcvrOLwpopimGPSu37KX2Md6Q4EceGJIdRuy6T3MCxzpseEDe+uXg mry6PWsv3w34DlkI6mNTkKB7UC2m1q20ZwZE9X3V9NE+tfFsa7YGwHVdNiZALyrAL8ih 5Bv+k+J7oZuLEEpZbja/upV10Qaf2663FGGa3GZ/zhadb8eC94a3UV+JMax/89Q9T1Hw 8pHA== MIME-Version: 1.0 X-Received: by 10.112.51.166 with SMTP id l6mr3767254lbo.5.1383765042615; Wed, 06 Nov 2013 11:10:42 -0800 (PST) Received: by 10.112.134.38 with HTTP; Wed, 6 Nov 2013 11:10:42 -0800 (PST) In-Reply-To: <000F54A2-D1EC-4608-9C64-8FCD9D5E0311@oracle.com> References: <000F54A2-D1EC-4608-9C64-8FCD9D5E0311@oracle.com> Date: Wed, 6 Nov 2013 11:10:42 -0800 Message-ID: From: Nat Sakimura To: Phil Hunt Content-Type: multipart/alternative; boundary=001a113366bcd15d0804ea86e78b Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] expired hotk spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 19:10:45 -0000 --001a113366bcd15d0804ea86e78b Content-Type: text/plain; charset=ISO-8859-1 Some comments to the draft[1] to invigorate the discussion: [1] https://datatracker.ietf.org/doc/draft-tschofenig-oauth-hotk/ *3.1. Binding a Key to an Access Token* ======================================= *3.1.1. Symmetric keys* ---------------------- The server is creating a symmetric key and returning it from the token endpoint. So, this is only doing the token endpoint - client - resource binding. Should we not do the entire flow starting from the authorization request? Re: Editor's note: My vote is to bake the key into the access token and encrypt it with the resource server's public key as discussed below. *3.1.2 Asymmetric Keys* --------------------- The same comment as symmetric case: Should we not start from the authorization request? On access token: why just an example? Should we not prescribe it completely? Or are we just talking about the "within a same security domain" stuff? I feel like hotk field should contain only one key. If it expires, we can get another token. Do we really need kid then? *3.2. Accessing a Protected Resource* ====================================== *3.2.1 Symmetric keys* ----------------------- Is it assuming that the resource server can pull the key from the authz server? If the resource and the server is in a different security domain, you would not want to do this. As stated above, we should bake the key into the access token and encrypt it with the resource server's public key. *3.2.2 Asymmetric keys* ---------------------- Let's not require TLS Channel Binding. It is hard right now. Let's do something simpler. FYI, I posted http://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-01that shows the flow starting from the authorization request to the resource access. It has been sitting on my laptop for a long time (like Aug. last year...) It has been very incomplete so I did not post it before but just posted it today to facilitate the discussion. Cheers, Nat 2013/11/4 Phil Hunt > > https://datatracker.ietf.org/doc/draft-tschofenig-oauth-hotk/ > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a113366bcd15d0804ea86e78b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Some comments to the draft[1] to invigorate the discussion= :=A0

[1]=A0https://datatracker.ietf.org/doc/d= raft-tschofenig-oauth-hotk/

3.1. =A0Binding a Key to an Access Token
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

3.1.1. Symmetric keys
-----------= -----------

The server is creating a symmetric key and returning it = from the token endpoint.
So, this is only doing the token endpoint - client - resource binding.
=
Should we not do the entire flow starting from the authorization reques= t?

Re: Editor's note: My vote is to bake the key into the acces= s token and encrypt it with the resource server's public key as discuss= ed below.

3.1.2 Asymmetric Keys
---------------------
The same comme= nt as symmetric case: Should we not start from the authorization request? <= br>
On access token: why just an example?
Should we not prescribe it= completely?
Or are we just talking about the "within a same security domain" = stuff?

I feel like hotk field should contain only one key.
If i= t expires, we can get another token.
Do we really need kid then?

3.2. =A0Accessing a Protected Resource
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

3.2.1 Symmetric keys
------------------= -----
Is it assuming that the resource server can pull the key from the = authz server?
If the resource and the server is in a different security domain, you would= not want to do this.

As stated above, we should bake the key into = the access token and encrypt it with the resource server's public key. =

3.2.2 Asymmetric keys
----------------------
Let's not= require TLS Channel Binding. It is hard right now. Let's do something = simpler.

FYI, I posted http://tools.ietf.org/html/draft-sakimura-oauth= -rjwtprof-01 that shows the flow starting from the authorization reques= t to the resource access. It has been sitting on my laptop for a long time = (like Aug. last year...) It has been very incomplete so I did not post it b= efore but just posted it today to facilitate the discussion.

Cheers,

Nat



2013/11/4 Phil Hunt <phil.hunt@oracle.com>
>
> htt= ps://datatracker.ietf.org/doc/draft-tschofenig-oauth-hotk/
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
> ____= ___________________________________________
> OAuth mailing list
> OAuth@iet= f.org
> h= ttps://www.ietf.org/mailman/listinfo/oauth
>



-- Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a113366bcd15d0804ea86e78b-- From ve7jtb@ve7jtb.com Wed Nov 6 11:33:19 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB63C21F9A3D for ; Wed, 6 Nov 2013 11:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2m6hDDSQfMOA for ; Wed, 6 Nov 2013 11:33:14 -0800 (PST) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id A61FA21F9A6C for ; Wed, 6 Nov 2013 11:33:12 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id md4so9468298pbc.30 for ; Wed, 06 Nov 2013 11:33:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=KHWK0I82OdkN69hEDPZnmCV8HkhWwa3r7D5fnNrnlRU=; b=EAvFynkxJSen8/vyuLtYTlv3m+StGEuJ9txfaNzozI+4cN5UgsvwdsDF6Mb5Tv89kS NGqnzdMtEBfeSMfgKspdDgA86GU2punjJAG10l5h4ZnbxMs/1KjfjGw7AuzxSqP1SvfC EAi8R0jcEqF0Sq8ju1ARhFLHP6563prTt+jc4YIX3zMbBeqAgqaEdlvx6h3aKP0UdX+T 3eM8tJQDhpQ0AFIhg6N7P0+4N/OtF5vVLbpro2K5IFGpnbut2hNXAEPQd2GSPUkSKuVT X4U8MYpqqhe48isy6POzIbQwp4V9zaoXhindpIFJ+KYvLdD8IL8GQ6ZUUrW2CZZ+tZO4 GXRw== X-Gm-Message-State: ALoCoQm5fJwXoFkUoqgWwIWsDbys2FJFnTEi7nzDjGHmxx8RkLV+kmQloeoAG8wi4n3hHWl/soJn X-Received: by 10.68.213.167 with SMTP id nt7mr4954537pbc.140.1383766391672; Wed, 06 Nov 2013 11:33:11 -0800 (PST) Received: from wireless-a-v6.meeting.ietf.org ([2001:67c:370:176:1c40:eff0:dc57:640]) by mx.google.com with ESMTPSA id qf7sm402806pac.14.2013.11.06.11.33.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 11:33:10 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_FD888D10-9F88-461C-983A-13D524F48A32"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: John Bradley In-Reply-To: Date: Wed, 6 Nov 2013 11:33:07 -0800 Message-Id: <9042E460-723A-408B-8261-4C078BCCB33B@ve7jtb.com> References: <625DD549-A737-4A49-963C-A6AC503BBA11@mitre.org> <04942DC4-C5C4-431A-80C9-0EC855285430@cisco.com> To: Brian Campbell X-Mailer: Apple Mail (2.1816) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] IETF WG Follow-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 19:33:19 -0000 --Apple-Mail=_FD888D10-9F88-461C-983A-13D524F48A32 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Are we meeting someplace now? On Nov 5, 2013, at 4:11 PM, Brian Campbell = wrote: > Both after the plenary tomorrow and/or after JOSE on Thus work for me. > Though not too much after as I've got other commitments later on both > days. >=20 > What about a "working lunch" tomorrow after the plenary? I bet even > Matt eats lunch... >=20 >=20 >=20 > On Tue, Nov 5, 2013 at 3:28 PM, Matt Miller (mamille2) > wrote: >>=20 >> On Nov 5, 2013, at 3:01 PM, Richer, Justin P. = wrote: >>=20 >>> At the end of Monday's WG session here at IETF, Derek suggested that = several of us who are here ought to get together and hash out some = detailed solutions to Dyn-Reg and related issues in person while we have = the opportunity. As such, I suggest that those of us who are interested = get together either tomorrow after the morning plenary session or on = Thursday after the JOSE session. I'm personally here for the remainder = of the week so I'm open to other concrete suggestions as well. >>>=20 >>> I'm even willing to bring my laptop along and we can try doing live = spec surgery if it comes to that. >>>=20 >>=20 >> I fully support this action, but unfortunately I'm not sure I = personally can participate before Friday afternoon. I'm not entirely = sure how much benefit I can provide directly, but am more than willing = to review the output. >>=20 >>=20 >> - m&m >>=20 >> Matt Miller < mamille2@cisco.com > >> Cisco Systems, Inc. >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_FD888D10-9F88-461C-983A-13D524F48A32 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMTA2MTkzMzA4WjAjBgkqhkiG9w0BCQQxFgQUjA/TG2fT iQ3jw0gyZV3cEcR0q/owgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAOeDkc1th+0mm14asG9ejGwHemwB/DSpTla7FOa6m YCgEuFTziooQmrGFwlL+Q30n2I70EQ6XAe8Igc+ILvOsxOzTIN/JOAK6zHBgvhSob2fmHGUh4IGc 7NCz2Z07kELr+3MWWYDmYJSofCgfMLeVXyUZlDd2kA8u8nOGK8GC+DD0V6wwj2LPxy0ufXTosDWa ybbZPlGSqDxxNNYYvnYhP0GVZ+GgjcF0LSlJIZ535R8iZCH/ng7XEG5VfB6AZIzTeEnO0H6hiWx9 umS7o8zgZfSYmzPPQ5jmbvMTdQlfIIxBJvQoHi9+2ICxX6Kzu6nS2MVYoawPnePMY/l+yB0jmQAA AAAAAA== --Apple-Mail=_FD888D10-9F88-461C-983A-13D524F48A32-- From sakimura@gmail.com Wed Nov 6 11:47:03 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD5421E8175 for ; Wed, 6 Nov 2013 11:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2VciNCjIS5o for ; Wed, 6 Nov 2013 11:47:01 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7243D21E80B6 for ; Wed, 6 Nov 2013 11:47:00 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id n7so5099679lam.13 for ; Wed, 06 Nov 2013 11:46:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:mime-version:in-reply-to:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=J3xoulJPGPM1YBROlBYn7r3dlU621l0YNBDV3XOwMOA=; b=gLyGeVA+nSWdfZsJRCn9cbcWk+MRkv+6nG9x4HaSNEXTbN18flaAmdxrZfA5olx6wE OzAvgvd+1+ZF0AoXrT+Yqu0lAVcpu9zMI9fsDiq/OxVymsiQTbo2VL7BXzRuk++3Ck2/ hiFYWW4PKnAskuP0z5Mz+Cr7aErpOhca5CyxdUkRMiEwzulmd94hfSDzY07dHHW9OVOm YxNqc0ACmicZxcr5eDB07WEiN1h2eHecnemCgbnSYtm3XL1CMEQTuP0JEPFZHqVmYhy7 KivGN/qrtP7yaEYFmFPySnkJEpbgv+BLN8xHYs/BYpHi7AdioKWGzULO8oOreCed5FVU iG0A== X-Received: by 10.152.216.167 with SMTP id or7mr3692262lac.10.1383767219487; Wed, 06 Nov 2013 11:46:59 -0800 (PST) References: <625DD549-A737-4A49-963C-A6AC503BBA11@mitre.org> <04942DC4-C5C4-431A-80C9-0EC855285430@cisco.com> <9042E460-723A-408B-8261-4C078BCCB33B@ve7jtb.com> From: Nat Sakimura Mime-Version: 1.0 (1.0) In-Reply-To: <9042E460-723A-408B-8261-4C078BCCB33B@ve7jtb.com> Date: Wed, 6 Nov 2013 11:43:42 -0800 Message-ID: <3909528243193653191@unknownmsgid> To: John Bradley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] IETF WG Follow-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 19:47:03 -0000 We did last night. =3Dnat via iPhone On Nov 6, 2013, at 11:33, John Bradley wrote: > Are we meeting someplace now? > > On Nov 5, 2013, at 4:11 PM, Brian Campbell w= rote: > >> Both after the plenary tomorrow and/or after JOSE on Thus work for me. >> Though not too much after as I've got other commitments later on both >> days. >> >> What about a "working lunch" tomorrow after the plenary? I bet even >> Matt eats lunch... >> >> >> >> On Tue, Nov 5, 2013 at 3:28 PM, Matt Miller (mamille2) >> wrote: >>> >>> On Nov 5, 2013, at 3:01 PM, Richer, Justin P. wrote= : >>> >>>> At the end of Monday's WG session here at IETF, Derek suggested that s= everal of us who are here ought to get together and hash out some detailed = solutions to Dyn-Reg and related issues in person while we have the opportu= nity. As such, I suggest that those of us who are interested get together e= ither tomorrow after the morning plenary session or on Thursday after the J= OSE session. I'm personally here for the remainder of the week so I'm open = to other concrete suggestions as well. >>>> >>>> I'm even willing to bring my laptop along and we can try doing live sp= ec surgery if it comes to that. >>> >>> I fully support this action, but unfortunately I'm not sure I personall= y can participate before Friday afternoon. I'm not entirely sure how much = benefit I can provide directly, but am more than willing to review the outp= ut. >>> >>> >>> - m&m >>> >>> Matt Miller < mamille2@cisco.com > >>> Cisco Systems, Inc. >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From derek@ihtfp.com Wed Nov 6 17:04:00 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8E911E81C0 for ; Wed, 6 Nov 2013 17:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.889 X-Spam-Level: X-Spam-Status: No, score=-101.889 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGauUk4JXaek for ; Wed, 6 Nov 2013 17:03:59 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 4856721E81BC for ; Wed, 6 Nov 2013 17:01:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 249C026029B for ; Wed, 6 Nov 2013 20:00:31 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 32040-01 for ; Wed, 6 Nov 2013 20:00:24 -0500 (EST) Received: from mocana.ihtfp.org (unknown [IPv6:2001:67c:370:176:224:d7ff:fee7:8924]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id CCA752600B9 for ; Wed, 6 Nov 2013 20:00:22 -0500 (EST) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.7/8.14.7/Submit) id rA710Lnn023049; Wed, 6 Nov 2013 20:00:21 -0500 From: Derek Atkins To: oauth@ietf.org Date: Wed, 06 Nov 2013 20:00:21 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Subject: [OAUTH-WG] Draft Minutes from IETF-88 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 01:04:00 -0000 NOTE: Please let me know if you find any issues with the minutes; I'll upload a final version with any necessary changes. -derek OAUTH WG - IETF 88 PARTICIPANTS ------------ * Anthony Nadlin (AN) * Brian Campbell (BN) * Derek Atkins (DA) * John Bradley (JB) * Justin Richer (JR) * Mike Jones (MJ) * Nat Sakamura (NS) * Phil Hunt (PH) * Prateek Mishra (PM) * Stephen Farrell (SF) * Tim Bray (TB) * Torsten Lodderstedt (TL) * Matt Miller (MM) Draft Statuses -------------- * draft-ietf-oauth-jwt-bearer :: Mike Jones is working to update from feedback * PH : At the end of Berlin, presented auth draft. Some changes to align with OpenID, but waiting on recharter discussion. Would like feedback. * NS : What is a good time to talk about recharter? * DA : Looks to AD -- let's finish some of the work we've got, then we can talk about adding more work. * SF : I don't think I saw discussion about recharter, and we have a number of knotty problems that need to be resolved first. * PM : I am confused about where we are with the SAML and assertions dtrafts? * DA : Waiting on Barry and Hannes to finish reviews -- can't do anything until they're done. * PM : Are there any substantive problems? * DA : None that I'm aware of * SF : Sometimes there's too much process in the IESG, so we're kind of waiting on the WG to finish. * NS : On recharter, should we postpone all the discussion on new documents until we get these other things done? I am puzzled by all the -00's while there's WG items to finish. * DA : These new drafts are toward the current charter items. * BN : My understanding -- came back from IESG after 86, and made significant changes. Now waiting on Hannes and other feedback. * DA : Hannes has been very busy with other activities, and can't get to these right now. We are waiting on Hannes right now. * JR : I suggest we fold stateless-client into dynamic registration. Proof of Possession (Anthony Nadlin) ------------------------------------ * PH : IIRC the MAC spec was folding in HotK, and we thought symmetric was sufficient. * JR : To follow up, we had decided that we wanted to do MAC (symmetric), but if we could do asymmetric as easily then we would. * JB : There was a feeling at the time that asymmetric with channel binding was too complicated, so we started off with the simplest (symmetric). I just sent a message to the list about why symmetric keys are bad. One advantage of asymmetric keys is that people do the right thing more often. * PM : Are you referencing a draft? * AN : Yes, there's a HotK draft (expired), that we think should be updated to talk about asymmetric keys. * PM : ANd you're proposing a new approach? * AN : No, I'm proposing we move it into the WG draft. * PH : On TLS channel binding, that was something exploring a new draft. It was interesting, but introduced a bunch of new questions. * AN : Channel binding was one approach, but there are others. I am proposing we update the HotK draft to talk about a couple of other ways. * JR : One feature from OAuth1 and other drafts, is to optionally sign parts of the HTTP message in addition to just the token. * AN : It gets into some issues, but if you have a specific use-case then we should talk about it. * JR : I brought them up on the list and in the call, but I can reiterate them again. And I think we can layer them into the JWT approach. * AN : But it's a different signature * JR : It's actually not -- it's just JWS. * MJ : I lost track -- does this require rechartering, and is recharting in flight? * DA : I don't think this draft requires rechartering, and we do not have a recharting in flight * TL : Did you want to remove symmetric? * NA : No, we just wanted to update the asymmetric part. ActAs/OnBefalfOf (Mike Jones) ----------------------------- * TL : Clarifying question: is the security token an assertion? * MJ : Yes, it's functionally equivalent. * TL : I suggest you use assertion. Also, is this meant to be a token, or an assertion? * MJ : It's an assertion. It might be used as an access token, but that is outside the scope of this. * TL : I suggest this go to another endpoint because it's not compliant to the current semantics * JR : I would like to see an alignment or clear delineation between this approach and where tokens have been used to get other tokens. I'm not going so far as to requiring a different endpoint, but I would like an alignment or delineation. * DA : What's the difference between of an assertion and a token? * JR : A token is completely opague to the client. * MJ : I take your point on comparing this to token-in/token-out approaches * PM : Is this a profile of the assertion draft? * MJ : No * PM : And this is not a profile is because this is returning an assertion? * MJ : There are several reasons -- you can use an assertion to get access tokens or authorization codes. We didn't want to jam a third thing into the assertions draft. * PM : I would like to see some standardization in this space * JB : I agree that I think this is a good pattern. I would have said that these tokens are encrypted for the intended audience, but are most likely opaque to the client. The intent is not to send structured tokens to the client, but to send structured tokens to the recipients through the client. It might be similar enough to overload, but we need to think carefully about it. * NS I think this support is for a very important use-cases. What's the relationship between OBO and OpenID-Connect ? * MJ : One is used as a client id for openid-connect, and one might be a security token for some other party. * NS : Where would this fall within our current charter? * DA : I don't think this falls within the current charter. * AN : I would also want to look at it as pure token exchanges. The current specs are rather ambiguous about what exactly is returned. I'm not opposed with the endpoint sending back specific token types. Also, this pattern matches what a lot of enterprises do today, so I think we need to extend this into OAuth. * TL : Why does this need to return structured tokens? I think the structured tokens limits us too much. * MJ : That might be, but the structure allows us to verify the identity. * JB : Note that an opaque token could be a reference, or it could be a structured token. * MJ : To be clear, I didn't talk about token references at all. * JB : Token references is also a legitimate design pattern. I have customers that can't use structured tokens. * MJ : OAuth already has artifacts -- authorization codes and access tokens * TL : WHo is the recipient? * MJ : THat is out of scope * TL : I suggest comparing this to the token exchange approach. I think this is very similar to the other approach. * MJ : I wrote this to get the discussion going, which it seems to do. But I want to know what the group wants to do next. * DA : I think we should take this to the list, and see if the WG wants to recharter to take on this work. * PH : I would like to see a fresh perspective on the use-case, since REST is point-to-point and more immediately needed, while WS-Trust is more end-to-end and not really needed. DynReg ------ * MJ : Some times you don't want to register at all. Purpose of registration is to get a client id. You could define ways to generate client ids without registering. Is that what you were getting at. * JR: The answer is yes. * JR : How I get the client id is independent. As a consequence we have two RFCs for that. We can get tokens in a number of different ways. * AN : Client doesn't know how to encode things. * JR : Assertions don't give you a client id. * PH : Are we addressing all the use cases? Transient use case; software statement which can be given out-of-band. Put in an identifier and that would be known to the end-point. Software state is a known profile. * JR : Client id is public information, bad idea for authentication purposes. Use only as a point of reference. Still useful for authorization server w/o having to reregister all the time. * MM : I'm going to needs this. We want to handle stateless client really well. Boot strap to oauth. If we can keep common ground that would be benefical for 3rd party clients. Need a standardized way of getting them. Not concerned of what's in them. * JR : Original use case for the client. Server wants to know what's in them. * MM : Important for clients on how to get them. * JR : Gives you reusable components. * JB : Can escalate privileges. We have a number of ways for doing client credentials. We identify through some credential or redirect. We can't blow a hole in our security model. We have a client with an opaque token for reference or assertion. What are we attempting to gaurantee registration identification. This is core to our security model. Have to allow for self assertion. * JR : I can make a client id, the server has to be very careful. The purpose of registration; there are two aspects; 1. the authz server needs an identifier 2. a client talks to multiple authz servers in different security domain. Dyn reg needs to solve both problems. * MJ : Tony said: We don't want to jam structed identifiers in the enterprise. Authz server chooses to issue structured identifier or authz server could advertize client identification structures. These are two separate choices for authz servers. We can define a simple registration structure and a separate structure for the non-registration case. * PH : Three registration modes; wanted to flesh out the various client types. * MM : The assertion that non-http client don't use URIs is false. Whatever structure we use, the bare minimums needs to be defined. * PH : For the client perspective, it needs to be consistent. * MM : We need to be consistent for the protocol used. * JR : Everything is optional -- hand waving. Send these fields ever time using this protocol. Connect does this already. * JB : Most protocols use URIs. Leave other options of identifying the client. * MM : There is an HTTP response with a location, it uses a URI. URI location doesn't have to be HTTP or HTTPs. * TB : Lots of use cases that should be considered, but are not being considered. * JR : Cred uid moved to optional. * MM : Dyn 14 works for me right now, could have clarifications on client implementations, etc. * TB : There are lots of use cases. * MJ : Support separation out core registration from the ability to update state. * AN : We've come up alternatives that solves are use cases. There are scalability issues with dyn 14. * PH : What are the use cases for a management API? It is not clear. Registration (Phil Hunt) ------------ * JR : I think a large part of the mismatch in the usefulness of a management API. If the client software is very fixed, then you don't need a management API. If it's more ephemeral, then management makes sense. * PH : Is it something really worth having a protocl for? * JR : If you have a manual admin process, then you don't need an API. But if you don't have an administrative step, then that's where it makes sense. * PH : If you allow your clients to be anything they want at any time, why would you let clients do this over protocol? * JR: You are conflating many different ascpects. Hackers aren't just going to do whatever they want, because presumably we have endpoints that require authentication/authorization. * JR : In the association draft, the token-in is the software statement, correct? * PH : Correct * JR : So changing the token-out is changing the software statement then? * PH : No, you can ask for the token type separate. * JR : So if your model calls for PKI, or etc, then you could do that without changing anything...? * JR : I see associations and dynreg as the same thing. What gets passed in is slightly different, but what gets passed out is what the client needs to know. With that, you could very easily send out a client_secret, or an assertion, or a certain token, without changing the registration at all. * PH : We did this move the ball forward thing. What we have today is a password that has to be stored. * JR : Passwords don't have to be stateful * PH : Why do you need it then? * JR : Because that's how OAuth works today * PH : It's not. Don't we want to move the ball forward? * JR : What you have could spit out a client secret or an assertion. Clients today assume HTTP with headers. * JR : One more point about client associations can't be reasonably implemented today, because the token endpoint takes in a set of form parameters (one of them being grant_type). Client association uses the same field name expressed in a JSON object, and that's fine because it's in the context of the JSON object. We used to have form parameter for dynreg, and decided to move to JSON. * JR : In order for my existing endpoints to implement this, I would need to examine the grant_type to determine if I am parsing form params or JSON. * BN (via JR) : He believed that JSON in was a confused portion of the client association. * JR : As an implementer, I know that I cannot do client associations * PH : Whether we have consensus or not, we could merge the specs. * JR : From my perspective, I don't think we can do client associations via the token endpoint; it would need to be a new endpoint. * PH : You said that a software statement is not possible. * JR : I have been supportive of software statement from the start. * PH : I don't see a point in closed loophole, except for Torsten's point about a token endpoint being just a token endpoint. We are defining a new profile, not a new endpoint. * JR : And my point, I don't think this is implementable as it is currently written. That said, parts about validating the registration should be merged in. * PH : Your point is well made. * JR : The Connect API says that the token endpoint could be the same as your registration endpoint, if you can handle it. What I want is the abiity to separate the functionality based on the endpoint. If you want to co-host it, then go ahead. but I think it's important not to require it. * PM : One point - just because draft allows for a client secret part of the spec, and human beings need passwords, but we need to be careful for using these for other functions because of the Lowest Common Denominator factor. * PM : Second point - what kind of token endpoint is appropriate, and that seems like a solvable issue. * PH : I say it doesn't matter, but there is merit to re-using the token endpoint. We do it all over the place. * PM : OK, if the current RFC doesn't accommodate that, then we need to address that. * PH : Everything is basically doing something-in to something-out. * JB : I think your presentation was lacking what you were proposing to merge, and some of us are confused. * PH : I was working with an open format discussion, and that was not clear from the slides. * JB : One thing that is similar is the software statement and my draft about a structured client_id. It was not specific to dynreg-14, it could be used with client assocications. You just need to get this to the authorization server, either with storing state or through the client id. Possibly how you create the JSON object and possibly sign it could be agreed on. * PH : One of the things I'm trying to get to is consistent use of the software statement. * JB : Having a client authenticate itself with an assertion is not really different from authenticating with a password. * PH : There is a differece. Dynamic registration its a registration step not an authentication step. You could try to track that the client returned again, and is that a worthwhile thing, I'm not sure. * JB : And it depends on what your notion of a transient client is. Just because it's Javascript running in a browser might not mean there isn't a central authority. * JB : Can we reach consensus on the following?: * JB : Perhaps we have some convergence on the stateless client parameters and software statements. Exactly what the parameters and the software statement there is some possible agreement. Exactly what endpoint is doing it might require extra shoehorning. The token endpoint isn't the one actually protected by OAuth. * PH : Does registration itself need to be protected. Which gets back to if we need a registration token. * PH : One of the reasons that I put software statement as a separate parameter is to try to not conflate all of this together. * JB : I think there are a couple of issues to sort out, and the sooner it happens the better. * AN : There is a lot of abuse about the endpoints today. The spec doesn't clear state that the endpoint only return one thing, and some things have implemented them together because they don't want them separate * TL : As an outside observer, I find this discussion very useful. I propose we really nail down the pros/cons about the approaches in order to move forward. * PH : It sounds like you say it's a more core issue. * DA : I encourage people continue to discuss this to keep making progress, but we haven't yet come to a conclusion. * Lucy Lynch : I just want to +1 all of this. We originally separated because we couldn't agree on it. I agree this is a realy important dialog, and I'm not sure anyone really understands what it means. -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From prateek.mishra@oracle.com Thu Nov 7 10:44:02 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E7B21E821C; Thu, 7 Nov 2013 10:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSsQjbjM5YPB; Thu, 7 Nov 2013 10:43:56 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2347321F9F70; Thu, 7 Nov 2013 10:43:33 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA7Ih6pp024661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Nov 2013 18:43:07 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA7Ih6HC025628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Nov 2013 18:43:06 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA7Ih5xM012207; Thu, 7 Nov 2013 18:43:05 GMT Received: from [130.35.50.47] (/130.35.50.47) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 07 Nov 2013 10:43:05 -0800 Message-ID: <527BDF38.6040106@oracle.com> Date: Thu, 07 Nov 2013 10:43:04 -0800 From: Prateek Mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130911 Thunderbird/17.0.9 MIME-Version: 1.0 To: security-services@lists.oasis-open.org, IETF oauth WG , scim@ietf.org References: <5E393DF26B791A428E5F003BB6C5342A322F6D72@OC11EXPO24.exchange.mit.edu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090408080407010604000603" X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [OAUTH-WG] FYI: The Java Identity Api - public review ongoing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:44:02 -0000 This is a multi-part message in MIME format. --------------090408080407010604000603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit ABSTRACT: The objective of this project is to define application programming interfaces and identity interaction models to facilitate the use and creation of identity by Java applications. To meet this objective, this specification defines a /representation for identity/ in Java, an /attribute/ service as a point of governance and interaction with identity, and an /identity repository integration/ architecture in support of distributed sources of identity. The identity representation is integrated with the Java security model and captures identity attributes as named, metadata qualified (e.g., issuer, validity period, usage constraints) representations of identity values. The attribute service is a protected service from which applications request interfaces to operate on the content of the integrated identity repositories. In addition to value based interactions with identity, and in support of privacy preserving exchange of identity, the attribute also service provides interfaces to obtain and operate on references to identity attributes. Above the interfaces provided by the attribute service, the specification also defines annotations and interceptor bindings that provide application developers with a simple means to cause identity attributes to be obtained or provided to the attribute service by an annotated application. More information available at: http://jcp.org/aboutJava/communityprocess/edr/jsr351/index.html --------------090408080407010604000603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

ABSTRACT:

The objective of this project is to define application programming interfaces and identity interaction models to facilitate the use and creation of identity by Java applications. To meet this objective, this specification defines a representation for identity in Java, an attribute service as a point of governance and interaction with identity, and an identity repository integration architecture in support of distributed sources of identity.

The identity representation is integrated with the Java security model and captures identity attributes as named, metadata qualified (e.g., issuer, validity period, usage constraints) representations of identity values. The attribute service is a protected service from which applications request interfaces to operate on the content of the integrated identity repositories. In addition to value based interactions with identity, and in support of privacy preserving exchange of identity, the attribute also service provides interfaces to obtain and operate on references to identity attributes. Above the interfaces provided by the attribute service, the specification also defines annotations and interceptor bindings that provide application developers with a simple means to cause identity attributes to be obtained or provided to the attribute service by an annotated application.

More information available at:
http://jcp.org/aboutJava/communityprocess/edr/jsr351/index.html

--------------090408080407010604000603-- From phil.hunt@oracle.com Thu Nov 7 15:54:55 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA6A21E808F; Thu, 7 Nov 2013 15:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMOvdYLiMXAs; Thu, 7 Nov 2013 15:54:48 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 93B8511E829E; Thu, 7 Nov 2013 15:54:41 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA7NsYAH006467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Nov 2013 23:54:35 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA7NsYS4020033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Nov 2013 23:54:34 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA7NsY8s020029; Thu, 7 Nov 2013 23:54:34 GMT Received: from [31.133.161.213] (/31.133.161.213) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 07 Nov 2013 15:54:34 -0800 From: Phil Hunt Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (11B511) Message-Id: <374F1417-8F59-47AA-8925-A491F36A3B58@oracle.com> Date: Thu, 7 Nov 2013 15:54:33 -0800 To: "oauth@ietf.org WG" , "scim@ietf.org WG" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [OAUTH-WG] Thurs tap and barrel X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 23:54:55 -0000 A bunch of us were talking about heading over to tap and barrel (near canada= place) for craft brew beer and barrel wine tasting.=20 Maybe a little scim/oauth on the side.=20 Suggest we meet for 6:30 at hotel lobby.=20 Phil= From derek@ihtfp.com Thu Nov 7 16:02:19 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD6311E8278; Thu, 7 Nov 2013 16:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.897 X-Spam-Level: X-Spam-Status: No, score=-101.897 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kEK9jN4mvQV; Thu, 7 Nov 2013 16:02:15 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 598D711E827F; Thu, 7 Nov 2013 16:02:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 5A1EF2602B2; Thu, 7 Nov 2013 19:02:13 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 06031-07; Thu, 7 Nov 2013 19:02:10 -0500 (EST) Received: by mail2.ihtfp.org (Postfix, from userid 48) id A6DF6260237; Thu, 7 Nov 2013 19:02:09 -0500 (EST) Received: from 31.133.180.131 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 7 Nov 2013 19:02:09 -0500 Message-ID: In-Reply-To: <374F1417-8F59-47AA-8925-A491F36A3B58@oracle.com> References: <374F1417-8F59-47AA-8925-A491F36A3B58@oracle.com> Date: Thu, 7 Nov 2013 19:02:09 -0500 From: "Derek Atkins" To: "Phil Hunt" User-Agent: SquirrelMail/1.4.22-2.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: "scim@ietf.org WG" , "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Thurs tap and barrel X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:02:19 -0000 I'll try to meet you at T&B; I have other dinner plans first. -derek On Thu, November 7, 2013 6:54 pm, Phil Hunt wrote: > A bunch of us were talking about heading over to tap and barrel (near > canada place) for craft brew beer and barrel wine tasting. > > Maybe a little scim/oauth on the side. > > Suggest we meet for 6:30 at hotel lobby. > > Phil > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From torsten@lodderstedt.net Sat Nov 9 05:24:05 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B9621F9D46 for ; Sat, 9 Nov 2013 05:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jdyoCOARY47 for ; Sat, 9 Nov 2013 05:24:00 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.29.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBBF11E80ED for ; Sat, 9 Nov 2013 05:23:57 -0800 (PST) Received: from [79.253.16.35] (helo=[192.168.71.44]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Vf8W3-0006Nv-Ms; Sat, 09 Nov 2013 14:23:55 +0100 Message-ID: <527E376C.2010205@lodderstedt.net> Date: Sat, 09 Nov 2013 14:23:56 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Nat Sakimura References: <20131019101348.9565.3370.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050805000505000109010103" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 13:24:05 -0000 This is a multi-part message in MIME format. --------------050805000505000109010103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Nat, what's the rationale for having different algorithms to produce a code challenges? As this may cause interop issues there should be good reasons to introduce variants. regards, Torsten. Am 19.10.2013 12:15, schrieb Nat Sakimura: > Incorporated the discussion at Berlin meeting and after in the ML. > > Best, > > Nat > > ---------- Forwarded message ---------- > From: > > Date: 2013/10/19 > Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt > To: Nat Sakimura >, > John Bradley >, Naveen Agarwal > > > > > A new version of I-D, draft-sakimura-oauth-tcse-02.txt > has been successfully submitted by Nat Sakimura and posted to the > IETF repository. > > Filename: draft-sakimura-oauth-tcse > Revision: 02 > Title: OAuth Symmetric Proof of Posession for Code Extension > Creation date: 2013-10-19 > Group: Individual Submission > Number of pages: 8 > URL: http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt > Status: http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse > Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02 > Diff: http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-tcse-02 > > Abstract: > The OAuth 2.0 public client utilizing authorization code grant is > susceptible to the code interception attack. This specification > describe a mechanism that acts as a control against this threat. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org > . > > The IETF Secretariat > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------050805000505000109010103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Nat,

what's the rationale for having different algorithms to produce a code challenges? As this may cause interop issues there should be good reasons to introduce variants.

regards,
Torsten.


Am 19.10.2013 12:15, schrieb Nat Sakimura:
Incorporated the discussion at Berlin meeting and after in the ML. 

Best, 

Nat

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: 2013/10/19
Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-02.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:        draft-sakimura-oauth-tcse
Revision:        02
Title:           OAuth Symmetric Proof of Posession for Code Extension
Creation date:   2013-10-19
Group:           Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-tcse-02

Abstract:
   The OAuth 2.0 public client utilizing authorization code grant is
   susceptible to the code interception attack.  This specification
   describe a mechanism that acts as a control against this threat.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------050805000505000109010103-- From ve7jtb@ve7jtb.com Sat Nov 9 07:51:39 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82EE21E80D9 for ; Sat, 9 Nov 2013 07:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.121 X-Spam-Level: X-Spam-Status: No, score=-3.121 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ee+05+IpnSt4 for ; Sat, 9 Nov 2013 07:51:35 -0800 (PST) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id 357B211E8122 for ; Sat, 9 Nov 2013 07:51:35 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id md4so3396073pbc.16 for ; Sat, 09 Nov 2013 07:51:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=LQbUsXxN8YkURCwCdP13UB8Ym79rbQabxACoL8kwQKg=; b=UgUBvRo9cd9uV5ieJnIrk02VZa2Bl+Bo6JkddpSRCYCcxSLHczJH8WgqkQFmPftPlR DQlGqvtvnMEbrifLrbMVMMLNK3eQYsRmHnd/OsCmvs/pE3OmHfqgV7VmXRXGI/pL2wPF Nk/sDEOIb+mrvOnp8a5V+zgLPJ9UixDW0WSQHqZjoqhGb9NtxEU85sGaju7TG8ZTs8mD 34GQEL3aT6cvTEw7FfzcwXCecc03kBrjFpixoI9aDy+UwgLRcnm4N5zjyrcN7ga1QVTr q5wIQI4fOUlVHn1BI+r0nWdYDZUlWUwxPi6eNDwfyTBupbXia/JEwhIvQYfUMVvxtJOQ x+3Q== X-Gm-Message-State: ALoCoQmPYmfVSo7vwMevYFOP730AImcP6LikKMQuMLED6WO9BxjKVZILV2uuHAuEgLGM3KNNw54T X-Received: by 10.66.26.110 with SMTP id k14mr1006456pag.171.1384012293794; Sat, 09 Nov 2013 07:51:33 -0800 (PST) Received: from [192.168.6.17] (199-91-80-194.ip.van.radiant.net. [199.91.80.194]) by mx.google.com with ESMTPSA id sg1sm19353081pbb.16.2013.11.09.07.51.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Nov 2013 07:51:32 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_3419D318-587B-47FD-BBFF-221FBEC7A5F3"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: John Bradley In-Reply-To: <527E376C.2010205@lodderstedt.net> Date: Sat, 9 Nov 2013 07:51:27 -0800 Message-Id: <001C64DB-2DD0-4740-8C9A-B7A0445F68CD@ve7jtb.com> References: <20131019101348.9565.3370.idtracker@ietfa.amsl.com> <527E376C.2010205@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1822) Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 15:51:40 -0000 --Apple-Mail=_3419D318-587B-47FD-BBFF-221FBEC7A5F3 Content-Type: multipart/alternative; boundary="Apple-Mail=_31F66582-0393-4082-9C0C-9302366A112C" --Apple-Mail=_31F66582-0393-4082-9C0C-9302366A112C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 With a native app using a captive browser with no malware, only the = response is susceptible to interception, making encrypting the request = redundant. In other environments and with some user groups the request's challenge = needs to be protected from interception. This may be more the case in a = desktop environment where there is less control over the browser. I expect that we will come to two options one unprotected requests and = one for protected requests. To Phil's point this is not about identifying the class of software this = is about matching a response to an instance of software. =20 A software statement gives you a hint about the class of software but = not the instance without per client registration. This method gives you the ability to securely return the token to only = the instance of the client that requested it without the overhead of per = instance dynamic registration. This is a practical solution to a real problem people are having today, = and versions of this are in production now. =20 Nat and I are trying to document it so that there can be = interoperability rather than every AS doing something different. John B. On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt = wrote: > Hi Nat, >=20 > what's the rationale for having different algorithms to produce a code = challenges? As this may cause interop issues there should be good = reasons to introduce variants. >=20 > regards, > Torsten. >=20 >=20 > Am 19.10.2013 12:15, schrieb Nat Sakimura: >> Incorporated the discussion at Berlin meeting and after in the ML.=20 >>=20 >> Best,=20 >>=20 >> Nat >>=20 >> ---------- Forwarded message ---------- >> From: >> Date: 2013/10/19 >> Subject: New Version Notification for = draft-sakimura-oauth-tcse-02.txt >> To: Nat Sakimura , John Bradley = , Naveen Agarwal >>=20 >>=20 >>=20 >> A new version of I-D, draft-sakimura-oauth-tcse-02.txt >> has been successfully submitted by Nat Sakimura and posted to the >> IETF repository. >>=20 >> Filename: draft-sakimura-oauth-tcse >> Revision: 02 >> Title: OAuth Symmetric Proof of Posession for Code = Extension >> Creation date: 2013-10-19 >> Group: Individual Submission >> Number of pages: 8 >> URL: = http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt >> Status: = http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse >> Htmlized: = http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02 >> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-oauth-tcse-02 >>=20 >> Abstract: >> The OAuth 2.0 public client utilizing authorization code grant is >> susceptible to the code interception attack. This specification >> describe a mechanism that acts as a control against this threat. >>=20 >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >>=20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_31F66582-0393-4082-9C0C-9302366A112C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 With a = native app using a captive browser with no malware, only the response is = susceptible to interception, making encrypting the request = redundant.
In other environments and with some user groups the = request's challenge needs to be protected from interception.  This = may be more the case in a desktop environment where there is less = control over the browser.

I expect that we will = come to two options one unprotected requests and one for protected = requests.

To Phil's point this is not about = identifying the class of software this is about matching a response to = an instance of software.   
A software statement = gives you a hint about the class of software but not the instance = without per client registration.

This method = gives you the ability to securely return the token to only the instance = of the client that requested it without the overhead of per instance = dynamic registration.

This is a practical = solution to a real problem people are having today, and versions of this = are in production now.   

Nat and I = are trying to document it so that there can be interoperability rather = than every AS doing something different.

John = B.

On Nov 9, 2013, at 5:23 AM, = Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

=20 =20
Hi Nat,

what's the rationale for having different algorithms to produce a code challenges? As this may cause interop issues there should be good reasons to introduce variants.

regards,
Torsten.


Am 19.10.2013 12:15, schrieb Nat Sakimura:
Incorporated the discussion at Berlin meeting and after in the ML. 

Best, 

Nat

---------- Forwarded message ----------
From: <internet-drafts@ietf.org><= /span>
Date: 2013/10/19
Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>= ;, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-02.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:       =  draft-sakimura-oauth-tcse
Revision:        02
Title:           OAuth Symmetric = Proof of Posession for Code Extension
Creation date:   2013-10-19
Group:           Individual = Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-sakimura-oauth= -tcse-02.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcs= e
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02<= /a>
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-oauth-= tcse-02

Abstract:
   The OAuth 2.0 public client utilizing = authorization code grant is
   susceptible to the code interception attack. =  This specification
   describe a mechanism that acts as a control = against this threat.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth

_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_31F66582-0393-4082-9C0C-9302366A112C-- --Apple-Mail=_3419D318-587B-47FD-BBFF-221FBEC7A5F3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMTA5MTU1MTI4WjAjBgkqhkiG9w0BCQQxFgQUgJ1IAEPn pj9aJuyvuHUX6CsytUowgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAT912/zMdWxuyKHmmIowEeAs5/Y8d3z+5Hauzq6SQ +Dki810tlvVz+n6JKJPjOKR6SjnEVIz4FB0g6zaD5sD3KbjIGj0vtyEnp4tTl+1m1sfi7mqkI4Q6 azvOMWKBBZvGShgZB2cfafVWxFjDdo7pf70XwEv9nKFa8904Ofsb6epTTub+vkwp+ciN2DbdXjg9 7KD+IB0Cl7szjvNu3v8v85wj/VvRur+eHeOirhTN/DMCZu6SOe+ezY7nmxHF3UbhVI30O1wTeN8C ZIwQgUJk/aAg86kEo29o4IGQEn1UpCc0Xgi+GwiP05mt5bsnpgx9Plfr7Bi9kTGZzRgJy07EUgAA AAAAAA== --Apple-Mail=_3419D318-587B-47FD-BBFF-221FBEC7A5F3-- From ve7jtb@ve7jtb.com Sat Nov 9 07:55:17 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC5B21E80CD for ; Sat, 9 Nov 2013 07:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MK7zl3uyN6zi for ; Sat, 9 Nov 2013 07:55:13 -0800 (PST) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB1A11E8136 for ; Sat, 9 Nov 2013 07:55:13 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id r10so3382598pdi.4 for ; Sat, 09 Nov 2013 07:55:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=JTDi3FRAdrVE1jmbpy6uCEfhKBC38KFUHvLVpMjw6U4=; b=OPEXHogqYs7G15XrB0f36VjXyysYgY/fxNi6x5w16aVrmwEyWnGgYspo9ohSBjMOW+ 8Fy8MLMank+MFtBzewUaGOBtCVD9kntOjpd+d028dl0WFotsWocLnltLG3uXAVwv2j9h 6g6ubbjsI2UeQ61zvUB8HrLKZGipJLvvwEBDzStg8562+bDpftDGif5Wbt2gVY4ztXeI 47vkHXlPx0jtmuy8GlWBItwj+/HnBEqvUPNgXqDdwRynUtm+Tk+/PJ+rjmPalY2WIOsN K0+zEQCGgZyiHZfLu5AzCez+NbSnrgTQgZESGuR/cPR9zzoWG6ZatF0/YmyOnLEmvcw7 +9IA== X-Gm-Message-State: ALoCoQlukT+oPnqKM2UnMuZ9ujexApH6RIOTFjHqlehG8VFlogPzjjdjaBka37KtVA8LKvRLE2Gl X-Received: by 10.66.162.73 with SMTP id xy9mr812034pab.172.1384012513284; Sat, 09 Nov 2013 07:55:13 -0800 (PST) Received: from [192.168.6.17] (199-91-80-194.ip.van.radiant.net. [199.91.80.194]) by mx.google.com with ESMTPSA id b3sm15143952pbu.38.2013.11.09.07.55.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Nov 2013 07:55:12 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_748E7BDF-BAFF-4CB0-83FB-4411EF33268C"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: John Bradley In-Reply-To: <001C64DB-2DD0-4740-8C9A-B7A0445F68CD@ve7jtb.com> Date: Sat, 9 Nov 2013 07:55:09 -0800 Message-Id: <03A01EFE-7654-45C5-94D5-E7A778C6B863@ve7jtb.com> References: <20131019101348.9565.3370.idtracker@ietfa.amsl.com> <527E376C.2010205@lodderstedt.net> <001C64DB-2DD0-4740-8C9A-B7A0445F68CD@ve7jtb.com> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1822) Cc: oauth Subject: Re: [OAUTH-WG] New Version Notification for draft-sakimura-oauth-tcse-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 15:55:18 -0000 --Apple-Mail=_748E7BDF-BAFF-4CB0-83FB-4411EF33268C Content-Type: multipart/alternative; boundary="Apple-Mail=_195D5D98-860F-4157-B15C-7BCA6179EA8E" --Apple-Mail=_195D5D98-860F-4157-B15C-7BCA6179EA8E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 PS I did resist the temptation of doing DH key agreement in the = Authorization request /response then using the agreed key as the code = proof. That would also be secure but not popular with developers. John B. On Nov 9, 2013, at 7:51 AM, John Bradley wrote: > With a native app using a captive browser with no malware, only the = response is susceptible to interception, making encrypting the request = redundant. > In other environments and with some user groups the request's = challenge needs to be protected from interception. This may be more the = case in a desktop environment where there is less control over the = browser. >=20 > I expect that we will come to two options one unprotected requests and = one for protected requests. >=20 > To Phil's point this is not about identifying the class of software = this is about matching a response to an instance of software. =20 > A software statement gives you a hint about the class of software but = not the instance without per client registration. >=20 > This method gives you the ability to securely return the token to only = the instance of the client that requested it without the overhead of per = instance dynamic registration. >=20 > This is a practical solution to a real problem people are having = today, and versions of this are in production now. =20 >=20 > Nat and I are trying to document it so that there can be = interoperability rather than every AS doing something different. >=20 > John B. >=20 > On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt = wrote: >=20 >> Hi Nat, >>=20 >> what's the rationale for having different algorithms to produce a = code challenges? As this may cause interop issues there should be good = reasons to introduce variants. >>=20 >> regards, >> Torsten. >>=20 >>=20 >> Am 19.10.2013 12:15, schrieb Nat Sakimura: >>> Incorporated the discussion at Berlin meeting and after in the ML.=20= >>>=20 >>> Best,=20 >>>=20 >>> Nat >>>=20 >>> ---------- Forwarded message ---------- >>> From: >>> Date: 2013/10/19 >>> Subject: New Version Notification for = draft-sakimura-oauth-tcse-02.txt >>> To: Nat Sakimura , John Bradley = , Naveen Agarwal >>>=20 >>>=20 >>>=20 >>> A new version of I-D, draft-sakimura-oauth-tcse-02.txt >>> has been successfully submitted by Nat Sakimura and posted to the >>> IETF repository. >>>=20 >>> Filename: draft-sakimura-oauth-tcse >>> Revision: 02 >>> Title: OAuth Symmetric Proof of Posession for Code = Extension >>> Creation date: 2013-10-19 >>> Group: Individual Submission >>> Number of pages: 8 >>> URL: = http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt >>> Status: = http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse >>> Htmlized: = http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02 >>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-oauth-tcse-02 >>>=20 >>> Abstract: >>> The OAuth 2.0 public client utilizing authorization code grant is >>> susceptible to the code interception attack. This specification >>> describe a mechanism that acts as a control against this threat. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>> Nat Sakimura (=3Dnat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_195D5D98-860F-4157-B15C-7BCA6179EA8E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 PS I = did resist the temptation of doing DH key agreement in the Authorization = request /response then using the agreed key as the code proof.
That = would also be secure but not popular with = developers.

John = B.

On Nov 9, 2013, at 7:51 AM, John = Bradley <ve7jtb@ve7jtb.com>= wrote:

With a = native app using a captive browser with no malware, only the response is = susceptible to interception, making encrypting the request = redundant.
In other environments and with some user groups the = request's challenge needs to be protected from interception.  This = may be more the case in a desktop environment where there is less = control over the browser.

I expect that we will = come to two options one unprotected requests and one for protected = requests.

To Phil's point this is not about = identifying the class of software this is about matching a response to = an instance of software.   
A software statement = gives you a hint about the class of software but not the instance = without per client registration.

This method = gives you the ability to securely return the token to only the instance = of the client that requested it without the overhead of per instance = dynamic registration.

This is a practical = solution to a real problem people are having today, and versions of this = are in production now.   

Nat and I = are trying to document it so that there can be interoperability rather = than every AS doing something different.

John = B.

On Nov 9, 2013, at 5:23 AM, = Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

=20 =20
Hi Nat,

what's the rationale for having different algorithms to produce a code challenges? As this may cause interop issues there should be good reasons to introduce variants.

regards,
Torsten.


Am 19.10.2013 12:15, schrieb Nat Sakimura:
Incorporated the discussion at Berlin meeting and after in the ML. 

Best, 

Nat

---------- Forwarded message ----------
From: <internet-drafts@ietf.org><= /span>
Date: 2013/10/19
Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>= ;, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-02.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:       =  draft-sakimura-oauth-tcse
Revision:        02
Title:           OAuth Symmetric = Proof of Posession for Code Extension
Creation date:   2013-10-19
Group:           Individual = Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-sakimura-oauth= -tcse-02.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcs= e
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02<= /a>
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-oauth-= tcse-02

Abstract:
   The OAuth 2.0 public client utilizing = authorization code grant is
   susceptible to the code interception attack. =  This specification
   describe a mechanism that acts as a control = against this threat.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth

_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


= --Apple-Mail=_195D5D98-860F-4157-B15C-7BCA6179EA8E-- --Apple-Mail=_748E7BDF-BAFF-4CB0-83FB-4411EF33268C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMTA5MTU1NTEwWjAjBgkqhkiG9w0BCQQxFgQUBk9CK5E7 eXrk+kGksiFHn1789s4wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAl+GQYyUGVJGFW5LZXJrveAgpQCObHVFxi8yYO9d9 2KAtJDLiB/TwpnObLCSBTzCYVwyH+TGkef9RSM2og5BH5hm7RP1RXUAd6sq+tnDPUU7xq98UW8Sd dX7RVRl1K16u5auLU+A3x/rvTm1jFjmX57E9zXLkp1inZkMLBvdTYPtPQxpy6BC28W3RwBJsuZWJ OG3Ep9T3giveTV6Pok4LoJvqQlp2eIxyj0GLLiHFRyhQTbtH6NG1+smSPrlHal9TB6jAiAYJO0Sk TV2qk6VMK0iM/XA1CzN68WiYh9hUQD+8dMA43NW7tzgPlfQ1LfwdTv1pYpyg85LiYcZuoMTvggAA AAAAAA== --Apple-Mail=_748E7BDF-BAFF-4CB0-83FB-4411EF33268C-- From torsten@lodderstedt.net Sat Nov 9 08:15:49 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E82D21E80D8 for ; Sat, 9 Nov 2013 08:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYelUD176s3p for ; Sat, 9 Nov 2013 08:15:40 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.29.24]) by ietfa.amsl.com (Postfix) with ESMTP id A555311E8136 for ; Sat, 9 Nov 2013 08:15:38 -0800 (PST) Received: from [80.187.110.117] (helo=[10.206.21.78]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1VfBCB-00015C-Tu; Sat, 09 Nov 2013 17:15:37 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <001C64DB-2DD0-4740-8C9A-B7A0445F68CD@ve7jtb.com> References: <20131019101348.9565.3370.idtracker@ietfa.amsl.com> <527E376C.2010205@lodderstedt.net> <001C64DB-2DD0-4740-8C9A-B7A0445F68CD@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----HMTYFX5JH8A3R61OGHOEBZ5U7R56C6" From: Torsten Lodderstedt Date: Sat, 09 Nov 2013 17:15:26 +0100 To: John Bradley Message-ID: X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 16:15:49 -0000 ------HMTYFX5JH8A3R61OGHOEBZ5U7R56C6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi John, why not make the more secure option the only one? regards, Torsten. John Bradley schrieb: >With a native app using a captive browser with no malware, only the >response is susceptible to interception, making encrypting the request >redundant. >In other environments and with some user groups the request's challenge >needs to be protected from interception. This may be more the case in >a desktop environment where there is less control over the browser. > >I expect that we will come to two options one unprotected requests and >one for protected requests. > >To Phil's point this is not about identifying the class of software >this is about matching a response to an instance of software. >A software statement gives you a hint about the class of software but >not the instance without per client registration. > >This method gives you the ability to securely return the token to only >the instance of the client that requested it without the overhead of >per instance dynamic registration. > >This is a practical solution to a real problem people are having today, >and versions of this are in production now. > >Nat and I are trying to document it so that there can be >interoperability rather than every AS doing something different. > >John B. > >On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt > wrote: > >> Hi Nat, >> >> what's the rationale for having different algorithms to produce a >code challenges? As this may cause interop issues there should be good >reasons to introduce variants. >> >> regards, >> Torsten. >> >> >> Am 19.10.2013 12:15, schrieb Nat Sakimura: >>> Incorporated the discussion at Berlin meeting and after in the ML. >>> >>> Best, >>> >>> Nat >>> >>> ---------- Forwarded message ---------- >>> From: >>> Date: 2013/10/19 >>> Subject: New Version Notification for >draft-sakimura-oauth-tcse-02.txt >>> To: Nat Sakimura , John Bradley >, Naveen Agarwal >>> >>> >>> >>> A new version of I-D, draft-sakimura-oauth-tcse-02.txt >>> has been successfully submitted by Nat Sakimura and posted to the >>> IETF repository. >>> >>> Filename: draft-sakimura-oauth-tcse >>> Revision: 02 >>> Title: OAuth Symmetric Proof of Posession for Code >Extension >>> Creation date: 2013-10-19 >>> Group: Individual Submission >>> Number of pages: 8 >>> URL: >http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt >>> Status: >http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse >>> Htmlized: >http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02 >>> Diff: >http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-tcse-02 >>> >>> Abstract: >>> The OAuth 2.0 public client utilizing authorization code grant is >>> susceptible to the code interception attack. This specification >>> describe a mechanism that acts as a control against this threat. >>> >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> >>> >>> >>> -- >>> Nat Sakimura (=nat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth ------HMTYFX5JH8A3R61OGHOEBZ5U7R56C6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi John,

why not make the more secure option the only one?

regards,
Torsten.



John Bradley <ve7jtb@ve7jtb.com> schrieb:
With a native app using a captive browser with no malware, only the response is susceptible to interception, making encrypting the request redundant.
In other environments and with some user groups the request's challenge needs to be protected from interception.  This may be more the case in a desktop environment where there is less control over the browser.

I expect that we will come to two options one unprotected requests and one for protected requests.

To Phil's point this is not about identifying the class of software this is about matching a response to an instance of software.   
A software statement gives you a hint about the class of software but not the instance without per client registration.

This method gives you the ability to securely return the token to only the instance of the client that requested it without the overhead of per instance dynamic registration.

This is a practical solution to a real problem people are having today, and versions of this are in production now.   

Nat and I are trying to document it so that there can be interoperability rather than every AS doing something different.

John B.

On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Nat,

what's the rationale for having different algorithms to produce a code challenges? As this may cause interop issues there should be good reasons to introduce variants.

regards,
Torsten.


Am 19.10.2013 12:15, schrieb Nat Sakimura:
Incorporated the discussion at Berlin meeting and after in the ML. 

Best, 

Nat

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: 2013/10/19
Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-02.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:        draft-sakimura-oauth-tcse
Revision:        02
Title:           OAuth Symmetric Proof of Posession for Code Extension
Creation date:   2013-10-19
Group:           Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-tcse-02

Abstract:
   The OAuth 2.0 public client utilizing authorization code grant is
   susceptible to the code interception attack.  This specification
   describe a mechanism that acts as a control against this threat.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

------HMTYFX5JH8A3R61OGHOEBZ5U7R56C6-- From ve7jtb@ve7jtb.com Sat Nov 9 08:42:56 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2997E21E80DC for ; Sat, 9 Nov 2013 08:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.178 X-Spam-Level: X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TwHECW5Rcpn for ; Sat, 9 Nov 2013 08:42:51 -0800 (PST) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by ietfa.amsl.com (Postfix) with ESMTP id 84C1521E80AD for ; Sat, 9 Nov 2013 08:42:51 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id rd3so655276pab.22 for ; Sat, 09 Nov 2013 08:42:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=f1vGABTwMoIdY7AdeNt+RHnr8hPc7jxd2ugduFUn5Yg=; b=IC5jmXOsa63qZCGG21bjNUdnMSSSltUEdcFikFnQ75iW9UIU93iEzygkCV2mabJSFq w5WnxkqmcpzJhSgrDupGKvZpE4ZhhjuLDYiZCINzzJ8yQpMeNrHLGwDtgsZwZda9szS4 PAVEDQykPw8l+lltpkocaVEoIGUI5jxCcY73ifTA9HkCKwuG5M3sGQ8Fg8kR75dnTfrH forNt0qmXmr4/y4URHbvZNMchF3mdLF9b/uz3oVEK4pY+W8MAn4sCssabskyoTgrstKZ 3/ueDI/SyZcE64I4aZPcOfjms9OY35ZoK4nKgV+/wR8CBxfV3gYbbjBD0IJH6mnRM74M OJJA== X-Gm-Message-State: ALoCoQksNlLlWQcdoJhpQgKMW04cOzlGRIkX7Hwv4ZFYlzilPNdx2U14yXl0lJEaCSGj2KVTnluj X-Received: by 10.68.247.106 with SMTP id yd10mr21426121pbc.25.1384015366366; Sat, 09 Nov 2013 08:42:46 -0800 (PST) Received: from [192.168.6.17] (199-91-80-194.ip.van.radiant.net. [199.91.80.194]) by mx.google.com with ESMTPSA id go4sm19582448pbb.15.2013.11.09.08.42.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Nov 2013 08:42:45 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_5F732FD4-5C9E-4B77-84B2-00FB08431611"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: John Bradley In-Reply-To: Date: Sat, 9 Nov 2013 08:42:41 -0800 Message-Id: <78E2CDE2-D49B-423E-AF13-097660FFB03F@ve7jtb.com> References: <20131019101348.9565.3370.idtracker@ietfa.amsl.com> <527E376C.2010205@lodderstedt.net> <001C64DB-2DD0-4740-8C9A-B7A0445F68CD@ve7jtb.com> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1822) Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 16:42:56 -0000 --Apple-Mail=_5F732FD4-5C9E-4B77-84B2-00FB08431611 Content-Type: multipart/alternative; boundary="Apple-Mail=_A4806170-F8FA-4105-BA7B-76921419E5E5" --Apple-Mail=_A4806170-F8FA-4105-BA7B-76921419E5E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Simplicity for clients that don't need the extra security. I happen to = agree with you but it is Google that needs the convincing, as they have = deployed the non crypto version. As with many things getting people to adopt it is the trick. John B. On Nov 9, 2013, at 8:15 AM, Torsten Lodderstedt = wrote: > Hi John, >=20 > why not make the more secure option the only one? >=20 > regards, > Torsten. >=20 >=20 >=20 > John Bradley schrieb: > With a native app using a captive browser with no malware, only the = response is susceptible to interception, making encrypting the request = redundant. > In other environments and with some user groups the request's = challenge needs to be protected from interception. This may be more the = case in a desktop environment where there is less control over the = browser. >=20 > I expect that we will come to two options one unprotected requests and = one for protected requests. >=20 > To Phil's point this is not about identifying the class of software = this is about matching a response to an instance of software. =20 > A software statement gives you a hint about the class of software but = not the instance without per client registration. >=20 > This method gives you the ability to securely return the token to only = the instance of the client that requested it without the overhead of per = instance dynamic registration. >=20 > This is a practical solution to a real problem people are having = today, and versions of this are in production now. =20 >=20 > Nat and I are trying to document it so that there can be = interoperability rather than every AS doing something different. >=20 > John B. >=20 > On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt = wrote: >=20 >> Hi Nat, >>=20 >> what's the rationale for having different algorithms to produce a = code challenges? As this may cause interop issues there should be good = reasons to introduce variants. >>=20 >> regards, >> Torsten. >>=20 >>=20 >> Am 19.10.2013 12:15, schrieb Nat Sakimura: >>> Incorporated the discussion at Berlin meeting and after in the ML.=20= >>>=20 >>> Best,=20 >>>=20 >>> Nat >>>=20 >>> ---------- Forwarded message ---------- >>> From: >>> Date: 2013/10/19 >>> Subject: New Version Notification for = draft-sakimura-oauth-tcse-02.txt >>> To: Nat Sakimura , John Bradley = , Naveen Agarwal >>>=20 >>>=20 >>>=20 >>> A new version of I-D, draft-sakimura-oauth-tcse-02.txt >>> has been successfully submitted by Nat Sakimura and posted to the >>> IETF repository. >>>=20 >>> Filename: draft-sakimura-oauth-tcse >>> Revision: 02 >>> Title: OAuth Symmetric Proof of Posession for Code = Extension >>> Creation date: 2013-10-19 >>> Group: Individual Submission >>> Number of pages: 8 >>> URL: = http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt >>> Status: = http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse >>> Htmlized: = http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02 >>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-oauth-tcse-02 >>>=20 >>> Abstract: >>> The OAuth 2.0 public client utilizing authorization code grant is >>> susceptible to the code interception attack. This specification >>> describe a mechanism that acts as a control against this threat. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>> Nat Sakimura (=3Dnat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_A4806170-F8FA-4105-BA7B-76921419E5E5 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Simplicity for clients that don't need the extra security.   I happen to agree with you but it is Google that needs the convincing, as they have deployed the non crypto version.
As with many things getting people to adopt it is the trick.

John B.

On Nov 9, 2013, at 8:15 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi John,

why not make the more secure option the only one?

regards,
Torsten.



John Bradley <ve7jtb@ve7jtb.com> schrieb:
With a native app using a captive browser with no malware, only the response is susceptible to interception, making encrypting the request redundant.
In other environments and with some user groups the request's challenge needs to be protected from interception.  This may be more the case in a desktop environment where there is less control over the browser.

I expect that we will come to two options one unprotected requests and one for protected requests.

To Phil's point this is not about identifying the class of software this is about matching a response to an instance of software.   
A software statement gives you a hint about the class of software but not the instance without per client registration.

This method gives you the ability to securely return the token to only the instance of the client that requested it without the overhead of per instance dynamic registration.

This is a practical solution to a real problem people are having today, and versions of this are in production now.   

Nat and I are trying to document it so that there can be interoperability rather than every AS doing something different.

John B.

On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Nat,

what's the rationale for having different algorithms to produce a code challenges? As this may cause interop issues there should be good reasons to introduce variants.

regards,
Torsten.


Am 19.10.2013 12:15, schrieb Nat Sakimura:
Incorporated the discussion at Berlin meeting and after in the ML. 

Best, 

Nat

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: 2013/10/19
Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-02.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:        draft-sakimura-oauth-tcse
Revision:        02
Title:           OAuth Symmetric Proof of Posession for Code Extension
Creation date:   2013-10-19
Group:           Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-tcse-02

Abstract:
   The OAuth 2.0 public client utilizing authorization code grant is
   susceptible to the code interception attack.  This specification
   describe a mechanism that acts as a control against this threat.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_A4806170-F8FA-4105-BA7B-76921419E5E5-- --Apple-Mail=_5F732FD4-5C9E-4B77-84B2-00FB08431611 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMTA5MTY0MjQxWjAjBgkqhkiG9w0BCQQxFgQUPsTsUtxb LIQpD5ACbUOiYMEaqtowgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEANYrR0yq6QjloZgMJNRibAU52/xCrI6xRtdm+2xSJ qkCwsk9m3oPXnS7oycbe/LdHcmY3Ytxpy642N0xTp1hfnp3VYIOzVUI5jMutNer/gQd4f5i2V+PU dmA75vmteYNqZZmkE91n3MEcxmlFFkdlBZtWpPuKt0RKKJeZrMC0S3X0niF9O54uAwGaEWISBk/F ShW7U6nopxEP5pf55Q2+pawxYfj2HnA3MDuFjyVKTtwh6BC4JX6UtTq46ZUdQ1LSpr0kDi5hMMI/ C/xxt4tud++pPDPNvxSfwmpLQx51R2hv+174GBLgd/BhL47zZFf9CnP1KFhcSWWRxpgJjqTthQAA AAAAAA== --Apple-Mail=_5F732FD4-5C9E-4B77-84B2-00FB08431611-- From sakimura@gmail.com Sat Nov 9 10:04:18 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F87521E80FE for ; Sat, 9 Nov 2013 10:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.439 X-Spam-Level: X-Spam-Status: No, score=-0.439 tagged_above=-999 required=5 tests=[AWL=-1.687, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwD1QWtC6q4S for ; Sat, 9 Nov 2013 10:04:09 -0800 (PST) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id C903C11E8177 for ; Sat, 9 Nov 2013 10:04:09 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id y10so3466055pdj.24 for ; Sat, 09 Nov 2013 10:04:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=5dsfLIomADv8RibSTv/UHRgXmmhvXlLR0IfwldxuT8s=; b=H0DalpddzYzkaQweuHtbvAY6boMCOXx3J+Bp163/bDwa+75+1/BPRkjy+KS5b5BGhb JqwRxrNJjeTmyQ4w4E4g/0WKPwe/0r5UQqWlafiCimkj/povuJ6Ai/X/pqJOYQicnwZ2 T4mL166mDIKA8ouvU7gFkQCy3vmV/qecYqdMrbsbmhIxwiwR52j9FLAp5xL/nKmtarM1 /b1Ik3hZKgl7u4MxUaQVwvR2Marp+cJ3Cc7i1Tz0sJxz4aFyuts2u26crq9T/Z0lCNiS Skkwq4I9xPGNWl7WF2bM3YA8+11AHlZjx1+XU5+WrObyMNHO96+82bgpB9ZRiXBlPH5S oBVA== X-Received: by 10.68.215.38 with SMTP id of6mr21489805pbc.14.1384020249385; Sat, 09 Nov 2013 10:04:09 -0800 (PST) Received: from [192.168.1.12] (gateway.marimba.org. [210.227.115.217]) by mx.google.com with ESMTPSA id nj9sm19918100pbc.13.2013.11.09.10.04.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Nov 2013 10:04:07 -0800 (PST) References: <20131019101348.9565.3370.idtracker@ietfa.amsl.com> <527E376C.2010205@lodderstedt.net> <001C64DB-2DD0-4740-8C9A-B7A0445F68CD@ve7jtb.com> <78E2CDE2-D49B-423E-AF13-097660FFB03F@ve7jtb.com> Mime-Version: 1.0 (1.0) In-Reply-To: <78E2CDE2-D49B-423E-AF13-097660FFB03F@ve7jtb.com> Content-Type: multipart/alternative; boundary=Apple-Mail-EB14997B-A9BC-4489-BC4C-F9D86480639A Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11B511) From: Nat Sakimura Date: Sun, 10 Nov 2013 03:04:03 +0900 To: John Bradley Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 18:04:18 -0000 --Apple-Mail-EB14997B-A9BC-4489-BC4C-F9D86480639A Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable And adding to it, it is Google's application team that needs to be persuaded= . As usual, persuading application people to use crypto is hard. We have to s= trike a point that is acceptable to them as well as being somewhat sensible s= ecurity-wise. Having option to bump up the security is important as a future= migration path as well, hence the current design.=20 =3Dnat via iPhone Nov 10, 2013 1:42=1B$B!"=1B(BJohn Bradley =1B$B$N%a%C%;!= <%8=1B(B: > Simplicity for clients that don't need the extra security. I happen to a= gree with you but it is Google that needs the convincing, as they have deplo= yed the non crypto version. > As with many things getting people to adopt it is the trick. >=20 > John B. >=20 >> On Nov 9, 2013, at 8:15 AM, Torsten Lodderstedt = wrote: >>=20 >> Hi John, >>=20 >> why not make the more secure option the only one? >>=20 >> regards, >> Torsten. >>=20 >>=20 >>=20 >> John Bradley schrieb: >>>=20 >>> With a native app using a captive browser with no malware, only the resp= onse is susceptible to interception, making encrypting the request redundant= . >>> In other environments and with some user groups the request's challenge n= eeds to be protected from interception. This may be more the case in a desk= top environment where there is less control over the browser. >>>=20 >>> I expect that we will come to two options one unprotected requests and o= ne for protected requests. >>>=20 >>> To Phil's point this is not about identifying the class of software this= is about matching a response to an instance of software. =20 >>> A software statement gives you a hint about the class of software but no= t the instance without per client registration. >>>=20 >>> This method gives you the ability to securely return the token to only t= he instance of the client that requested it without the overhead of per inst= ance dynamic registration. >>>=20 >>> This is a practical solution to a real problem people are having today, a= nd versions of this are in production now. =20 >>>=20 >>> Nat and I are trying to document it so that there can be interoperabilit= y rather than every AS doing something different. >>>=20 >>> John B. >>>=20 >>>> On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt wrote: >>>>=20 >>>> Hi Nat, >>>>=20 >>>> what's the rationale for having different algorithms to produce a code c= hallenges? As this may cause interop issues there should be good reasons to i= ntroduce variants. >>>>=20 >>>> regards, >>>> Torsten. >>>>=20 >>>>=20 >>>> Am 19.10.2013 12:15, schrieb Nat Sakimura: >>>>> Incorporated the discussion at Berlin meeting and after in the ML.=20 >>>>>=20 >>>>> Best,=20 >>>>>=20 >>>>> Nat >>>>>=20 >>>>> ---------- Forwarded message ---------- >>>>> From: >>>>> Date: 2013/10/19 >>>>> Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt= >>>>> To: Nat Sakimura , John Bradley , Naveen Agarwal >>>>>=20 >>>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-sakimura-oauth-tcse-02.txt >>>>> has been successfully submitted by Nat Sakimura and posted to the >>>>> IETF repository. >>>>>=20 >>>>> Filename: draft-sakimura-oauth-tcse >>>>> Revision: 02 >>>>> Title: OAuth Symmetric Proof of Posession for Code Extension= >>>>> Creation date: 2013-10-19 >>>>> Group: Individual Submission >>>>> Number of pages: 8 >>>>> URL: http://www.ietf.org/internet-drafts/draft-sakimura-oa= uth-tcse-02.txt >>>>> Status: http://datatracker.ietf.org/doc/draft-sakimura-oauth-= tcse >>>>> Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-tcse-= 02 >>>>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-oau= th-tcse-02 >>>>>=20 >>>>> Abstract: >>>>> The OAuth 2.0 public client utilizing authorization code grant is >>>>> susceptible to the code interception attack. This specification >>>>> describe a mechanism that acts as a control against this threat. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Please note that it may take a couple of minutes from the time of subm= ission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>=20 >>>>> The IETF Secretariat >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> Nat Sakimura (=3Dnat) >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-EB14997B-A9BC-4489-BC4C-F9D86480639A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
And adding to it, it is Google's appli= cation team that needs to be persuaded. As usual, persuading application peo= ple to use crypto is hard. We have to strike a point that is acceptable to t= hem as well as being somewhat sensible security-wise. Having option to bump u= p the security is important as a future migration path as well, hence the cu= rrent design. 

=3Dnat via iPhone

Nov 10, 2013 1:42= =E3=80=81John Bradley <ve7jtb@ve7jtb= .com> =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:

=
Simplicity for clients that don't need t= he extra security.   I happen to agree with you but it is Google that n= eeds the convincing, as they have deployed the non crypto version.
As wi= th many things getting people to adopt it is the trick.

=
John B.

On Nov 9, 2013, at 8:15 AM, T= orsten Lodderstedt <torsten@lo= dderstedt.net> wrote:

Hi John,

why not make the more secure option the only one?

regards,
Torsten.



John Bradley <ve7jtb@ve7jtb.com&= gt; schrieb:
With a native app using a captive browser with no malware, only the response= is susceptible to interception, making encrypting the request redundant.In other environments and with some user groups the request's challenge ne= eds to be protected from interception.  This may be more the case in a d= esktop environment where there is less control over the browser.
<= br>
I expect that we will come to two options one unprotected requ= ests and one for protected requests.

To Phil's poin= t this is not about identifying the class of software this is about matching= a response to an instance of software.   
A software st= atement gives you a hint about the class of software but not the instance wi= thout per client registration.

This method gives yo= u the ability to securely return the token to only the instance of the clien= t that requested it without the overhead of per instance dynamic registration.

This is a practical solution to a rea= l problem people are having today, and versions of this are in production no= w.   

Nat and I are trying to document it= so that there can be interoperability rather than every AS doing something d= ifferent.

John B.

On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=20 =20 =20
Hi Nat,

what's the rationale for having different algorithms to produce a code challenges? As this may cause interop issues there should be good reasons to introduce variants.

regards,
Torsten.


Am 19.10.2013 12:15, schrieb Nat Sakimura:
Incorporated the discussion at Berlin meeting and after in the ML. 

Best, 

Nat

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
= Date: 2013/10/19
Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-02.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:        draft-sakimura-oauth-tcse Revision:        02
Title:           OAuth Symmetric Proof o= f Posession for Code Extension
Creation date:   2013-10-19
Group:           Individual Submission<= br> Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-sak= imura-oauth-tcse-02.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse=
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-= oauth-tcse-02

Abstract:
   The OAuth 2.0 public client utilizing authorization= code grant is
   susceptible to the code interception attack.  = This specification
   describe a mechanism that acts as a control against= this threat.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.iet= f.org.

The IETF Secretariat




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
OAuth mailing list
OAuth@i=
etf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= /a>


= --Apple-Mail-EB14997B-A9BC-4489-BC4C-F9D86480639A-- From phil.hunt@oracle.com Sat Nov 9 12:21:35 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A66D21F9FDA for ; Sat, 9 Nov 2013 12:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.567 X-Spam-Level: X-Spam-Status: No, score=-5.567 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fluiZSZiMXil for ; Sat, 9 Nov 2013 12:21:30 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABAA21F9E9A for ; Sat, 9 Nov 2013 12:21:30 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA9KLQtn028435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 9 Nov 2013 20:21:27 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA9KLQF2012998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Nov 2013 20:21:26 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA9KLP98025411; Sat, 9 Nov 2013 20:21:25 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 09 Nov 2013 12:21:25 -0800 References: <20131019101348.9565.3370.idtracker@ietfa.amsl.com> <527E376C.2010205@lodderstedt.net> <001C64DB-2DD0-4740-8C9A-B7A0445F68CD@ve7jtb.com> <78E2CDE2-D49B-423E-AF13-097660FFB03F@ve7jtb.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-C8C94812-3DBB-4CF6-AF83-F2C47124A654 Content-Transfer-Encoding: 7bit Message-Id: <67DF012F-D3F3-4D44-89C6-7A52BB1657EF@oracle.com> X-Mailer: iPhone Mail (11B511) From: Phil Hunt Date: Sat, 9 Nov 2013 12:21:22 -0800 To: Nat Sakimura X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 20:21:35 -0000 --Apple-Mail-C8C94812-3DBB-4CF6-AF83-F2C47124A654 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable We may speculatively satisfy google and upset even more developers by creati= ng more options. I think google eng should be more directly involved in this= discussion and make the case.=20 That said, i do agree with John's analysis that some clients don't benefit. J= ust worry that the downgraded google option will always tend to be used. I w= ould prefer to go with a single more secure alg as the common solution.=20 Phil > On Nov 9, 2013, at 10:04, Nat Sakimura wrote: >=20 > And adding to it, it is Google's application team that needs to be persuad= ed. As usual, persuading application people to use crypto is hard. We have t= o strike a point that is acceptable to them as well as being somewhat sensib= le security-wise. Having option to bump up the security is important as a fu= ture migration path as well, hence the current design.=20 >=20 > =3Dnat via iPhone >=20 > Nov 10, 2013 1:42=E3=80=81John Bradley =E3=81=AE=E3=83= =A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8: >=20 >> Simplicity for clients that don't need the extra security. I happen to a= gree with you but it is Google that needs the convincing, as they have deplo= yed the non crypto version. >> As with many things getting people to adopt it is the trick. >>=20 >> John B. >>=20 >>> On Nov 9, 2013, at 8:15 AM, Torsten Lodderstedt wrote: >>>=20 >>> Hi John, >>>=20 >>> why not make the more secure option the only one? >>>=20 >>> regards, >>> Torsten. >>>=20 >>>=20 >>>=20 >>> John Bradley schrieb: >>>>=20 >>>> With a native app using a captive browser with no malware, only the res= ponse is susceptible to interception, making encrypting the request redundan= t. >>>> In other environments and with some user groups the request's challenge= needs to be protected from interception. This may be more the case in a de= sktop environment where there is less control over the browser. >>>>=20 >>>> I expect that we will come to two options one unprotected requests and o= ne for protected requests. >>>>=20 >>>> To Phil's point this is not about identifying the class of software thi= s is about matching a response to an instance of software. =20 >>>> A software statement gives you a hint about the class of software but n= ot the instance without per client registration. >>>>=20 >>>> This method gives you the ability to securely return the token to only t= he instance of the client that requested it without the overhead of per inst= ance dynamic registration. >>>>=20 >>>> This is a practical solution to a real problem people are having today,= and versions of this are in production now. =20 >>>>=20 >>>> Nat and I are trying to document it so that there can be interoperabili= ty rather than every AS doing something different. >>>>=20 >>>> John B. >>>>=20 >>>>> On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt wrote: >>>>>=20 >>>>> Hi Nat, >>>>>=20 >>>>> what's the rationale for having different algorithms to produce a code= challenges? As this may cause interop issues there should be good reasons t= o introduce variants. >>>>>=20 >>>>> regards, >>>>> Torsten. >>>>>=20 >>>>>=20 >>>>> Am 19.10.2013 12:15, schrieb Nat Sakimura: >>>>>> Incorporated the discussion at Berlin meeting and after in the ML.=20= >>>>>>=20 >>>>>> Best,=20 >>>>>>=20 >>>>>> Nat >>>>>>=20 >>>>>> ---------- Forwarded message ---------- >>>>>> From: >>>>>> Date: 2013/10/19 >>>>>> Subject: New Version Notification for draft-sakimura-oauth-tcse-02.tx= t >>>>>> To: Nat Sakimura , John Bradley , Naveen Agarwal >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> A new version of I-D, draft-sakimura-oauth-tcse-02.txt >>>>>> has been successfully submitted by Nat Sakimura and posted to the >>>>>> IETF repository. >>>>>>=20 >>>>>> Filename: draft-sakimura-oauth-tcse >>>>>> Revision: 02 >>>>>> Title: OAuth Symmetric Proof of Posession for Code Extensio= n >>>>>> Creation date: 2013-10-19 >>>>>> Group: Individual Submission >>>>>> Number of pages: 8 >>>>>> URL: http://www.ietf.org/internet-drafts/draft-sakimura-o= auth-tcse-02.txt >>>>>> Status: http://datatracker.ietf.org/doc/draft-sakimura-oauth= -tcse >>>>>> Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-tcse= -02 >>>>>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-oa= uth-tcse-02 >>>>>>=20 >>>>>> Abstract: >>>>>> The OAuth 2.0 public client utilizing authorization code grant is >>>>>> susceptible to the code interception attack. This specification >>>>>> describe a mechanism that acts as a control against this threat. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Please note that it may take a couple of minutes from the time of sub= mission >>>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>>=20 >>>>>> The IETF Secretariat >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>> Nat Sakimura (=3Dnat) >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-C8C94812-3DBB-4CF6-AF83-F2C47124A654 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

We may speculatively sa= tisfy google and upset even more developers by creating more options. I thin= k google eng should be more directly involved in this discussion and make th= e case. 

That said, i do agree with John's ana= lysis that some clients don't benefit. Just worry that the downgraded google= option will always tend to be used. I would prefer to go with a single more= secure alg as the common solution. 

Phil
And adding to it, it is Google's application team that ne= eds to be persuaded. As usual, persuading application people to use crypto i= s hard. We have to strike a point that is acceptable to them as well as bein= g somewhat sensible security-wise. Having option to bump up the security is i= mportant as a future migration path as well, hence the current design. =

=3Dnat via iPhone

Nov 10, 2013 1:42=E3=80=81John Bradl= ey <ve7jtb@ve7jtb.com> =E3=81= =AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:

Simplicity for clients that don't need the extra security. &= nbsp; I happen to agree with you but it is Google that needs the convincing,= as they have deployed the non crypto version.
As with many things getti= ng people to adopt it is the trick.

John B.

On Nov 9, 2013, at 8:15 AM, Torsten Lodderstedt &= lt;torsten@lodderstedt.net>= ; wrote:

Hi John,

why not make the more secure option the only one?

regards,
Torsten.



John Bradley <ve7jtb@ve7jtb.com&= gt; schrieb:
With a native app using a captive browser with no malware, only the response= is susceptible to interception, making encrypting the request redundant.In other environments and with some user groups the request's challenge ne= eds to be protected from interception.  This may be more the case in a d= esktop environment where there is less control over the browser.
<= br>
I expect that we will come to two options one unprotected requ= ests and one for protected requests.

To Phil's poin= t this is not about identifying the class of software this is about matching= a response to an instance of software.   
A software st= atement gives you a hint about the class of software but not the instance wi= thout per client registration.

This method gives yo= u the ability to securely return the token to only the instance of the clien= t that requested it without the overhead of per instance dynamic registration.

This is a practical solution to a rea= l problem people are having today, and versions of this are in production no= w.   

Nat and I are trying to document it= so that there can be interoperability rather than every AS doing something d= ifferent.

John B.

On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=20 =20 =20
Hi Nat,

what's the rationale for having different algorithms to produce a code challenges? As this may cause interop issues there should be good reasons to introduce variants.

regards,
Torsten.


Am 19.10.2013 12:15, schrieb Nat Sakimura:
Incorporated the discussion at Berlin meeting and after in the ML. 

Best, 

Nat

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
= Date: 2013/10/19
Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-02.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:        draft-sakimura-oauth-tcse Revision:        02
Title:           OAuth Symmetric Proof o= f Posession for Code Extension
Creation date:   2013-10-19
Group:           Individual Submission<= br> Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-sak= imura-oauth-tcse-02.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse=
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-= oauth-tcse-02

Abstract:
   The OAuth 2.0 public client utilizing authorization= code grant is
   susceptible to the code interception attack.  = This specification
   describe a mechanism that acts as a control against= this threat.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.iet= f.org.

The IETF Secretariat




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
OAuth mailing list
OAuth@i=
etf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= /a>


= --Apple-Mail-C8C94812-3DBB-4CF6-AF83-F2C47124A654-- From torsten@lodderstedt.net Sat Nov 9 12:28:00 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9281221E8096 for ; Sat, 9 Nov 2013 12:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6HKvduZo3PZ for ; Sat, 9 Nov 2013 12:27:56 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by ietfa.amsl.com (Postfix) with ESMTP id ACB0821F9FF6 for ; Sat, 9 Nov 2013 12:27:43 -0800 (PST) Received: from [79.253.16.35] (helo=[192.168.71.54]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1VfF8A-0003A1-0A; Sat, 09 Nov 2013 21:27:42 +0100 References: <20131019101348.9565.3370.idtracker@ietfa.amsl.com> <527E376C.2010205@lodderstedt.net> <001C64DB-2DD0-4740-8C9A-B7A0445F68CD@ve7jtb.com> <78E2CDE2-D49B-423E-AF13-097660FFB03F@ve7jtb.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-DA3BE550-2889-4DCE-AA17-C10C0CCA6E03 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (11B511) From: Torsten Lodderstedt Date: Sat, 9 Nov 2013 21:27:42 +0100 To: Nat Sakimura X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 20:28:00 -0000 --Apple-Mail-DA3BE550-2889-4DCE-AA17-C10C0CCA6E03 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, thanks for the explanation. Seems there is the simpler option sufficient to s= olve the original problem but it's not secure enough to be a general solutio= n.=20 Regarding implementation: The simpler option requires the developer to creat= e a value of reasonable randomness and the second additionally requires to c= alculate the SHA correctly. I'm afraid client developers will have trouble i= mplementing it correctly. That's why the idea of OAuth always was to push co= mplexity to the server implementation. While thinking about your proposal, I remembered a potential alternative. We= initially discussed usage of dynamically issued client id/secrets (dyn. cli= ent registration) in order to mitigate the threat. This has two advantages: - it utilizes general OAuth functionality - usage of client credentials is easy from a client developers perspective This idea was originally rejected due to the potential implications on scala= bility. The assumption was, potentially billions of client instances could n= ot be managed by the AS in a reasonable way. Based on the outcome of the lat= est discussions around dynamic registration, we now know how to implement re= gistration in a stateless way using client secrets as self-contained tokens.= So this should not be a scalability issue any longer. Should we reconsider this alternative? regards, Torsten. > Am 09.11.2013 um 19:04 schrieb Nat Sakimura : >=20 > And adding to it, it is Google's application team that needs to be persuad= ed. As usual, persuading application people to use crypto is hard. We have t= o strike a point that is acceptable to them as well as being somewhat sensib= le security-wise. Having option to bump up the security is important as a fu= ture migration path as well, hence the current design.=20 >=20 > =3Dnat via iPhone >=20 > Nov 10, 2013 1:42=E3=80=81John Bradley =E3=81=AE=E3=83= =A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8: >=20 >> Simplicity for clients that don't need the extra security. I happen to a= gree with you but it is Google that needs the convincing, as they have deplo= yed the non crypto version. >> As with many things getting people to adopt it is the trick. >>=20 >> John B. >>=20 >>> On Nov 9, 2013, at 8:15 AM, Torsten Lodderstedt wrote: >>>=20 >>> Hi John, >>>=20 >>> why not make the more secure option the only one? >>>=20 >>> regards, >>> Torsten. >>>=20 >>>=20 >>>=20 >>> John Bradley schrieb: >>>>=20 >>>> With a native app using a captive browser with no malware, only the res= ponse is susceptible to interception, making encrypting the request redundan= t. >>>> In other environments and with some user groups the request's challenge= needs to be protected from interception. This may be more the case in a de= sktop environment where there is less control over the browser. >>>>=20 >>>> I expect that we will come to two options one unprotected requests and o= ne for protected requests. >>>>=20 >>>> To Phil's point this is not about identifying the class of software thi= s is about matching a response to an instance of software. =20 >>>> A software statement gives you a hint about the class of software but n= ot the instance without per client registration. >>>>=20 >>>> This method gives you the ability to securely return the token to only t= he instance of the client that requested it without the overhead of per inst= ance dynamic registration. >>>>=20 >>>> This is a practical solution to a real problem people are having today,= and versions of this are in production now. =20 >>>>=20 >>>> Nat and I are trying to document it so that there can be interoperabili= ty rather than every AS doing something different. >>>>=20 >>>> John B. >>>>=20 >>>>> On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt wrote: >>>>>=20 >>>>> Hi Nat, >>>>>=20 >>>>> what's the rationale for having different algorithms to produce a code= challenges? As this may cause interop issues there should be good reasons t= o introduce variants. >>>>>=20 >>>>> regards, >>>>> Torsten. >>>>>=20 >>>>>=20 >>>>> Am 19.10.2013 12:15, schrieb Nat Sakimura: >>>>>> Incorporated the discussion at Berlin meeting and after in the ML.=20= >>>>>>=20 >>>>>> Best,=20 >>>>>>=20 >>>>>> Nat >>>>>>=20 >>>>>> ---------- Forwarded message ---------- >>>>>> From: >>>>>> Date: 2013/10/19 >>>>>> Subject: New Version Notification for draft-sakimura-oauth-tcse-02.tx= t >>>>>> To: Nat Sakimura , John Bradley , Naveen Agarwal >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> A new version of I-D, draft-sakimura-oauth-tcse-02.txt >>>>>> has been successfully submitted by Nat Sakimura and posted to the >>>>>> IETF repository. >>>>>>=20 >>>>>> Filename: draft-sakimura-oauth-tcse >>>>>> Revision: 02 >>>>>> Title: OAuth Symmetric Proof of Posession for Code Extensio= n >>>>>> Creation date: 2013-10-19 >>>>>> Group: Individual Submission >>>>>> Number of pages: 8 >>>>>> URL: http://www.ietf.org/internet-drafts/draft-sakimura-o= auth-tcse-02.txt >>>>>> Status: http://datatracker.ietf.org/doc/draft-sakimura-oauth= -tcse >>>>>> Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-tcse= -02 >>>>>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-oa= uth-tcse-02 >>>>>>=20 >>>>>> Abstract: >>>>>> The OAuth 2.0 public client utilizing authorization code grant is >>>>>> susceptible to the code interception attack. This specification >>>>>> describe a mechanism that acts as a control against this threat. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Please note that it may take a couple of minutes from the time of sub= mission >>>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>>=20 >>>>>> The IETF Secretariat >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>> Nat Sakimura (=3Dnat) >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>=20 --Apple-Mail-DA3BE550-2889-4DCE-AA17-C10C0CCA6E03 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

thanks fo= r the explanation. Seems there is the simpler option sufficient to solve the= original problem but it's not secure enough to be a general solution. =

Regarding implementation: The simpler option requi= res the developer to create a value of reasonable randomness and the second a= dditionally requires to calculate the SHA correctly. I'm afraid client devel= opers will have trouble implementing it correctly. That's why the idea of OA= uth always was to push complexity to the server implementation.
While thinking about your proposal, I remembered a potential al= ternative. We initially discussed usage of dynamically issued client id/secr= ets (dyn. client registration) in order to mitigate the threat. This has two= advantages:
- it utilizes general OAuth functionality
-= usage of client credentials is easy from a client developers perspective

This idea was originally rejected due to the potentia= l implications on scalability. The assumption was, potentially billions of c= lient instances could not be managed by the AS in a reasonable way. Based on= the outcome of the latest discussions around dynamic registration, we now k= now how to implement registration in a stateless way using client secrets as= self-contained tokens. So this should not be a scalability issue any longer= .

Should we reconsider this alternative?
=
regards,
Torsten.

Am 09.11.2013 um 19= :04 schrieb Nat Sakimura <sakimura@= gmail.com>:

And adding t= o it, it is Google's application team that needs to be persuaded. As usual, p= ersuading application people to use crypto is hard. We have to strike a poin= t that is acceptable to them as well as being somewhat sensible security-wis= e. Having option to bump up the security is important as a future migration p= ath as well, hence the current design. 

=3Dnat via iPhone
<= div>
Nov 10, 2013 1:42=E3=80=81John Bradley <ve7jtb@ve7jtb.com> =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3= =83=BC=E3=82=B8:

Simplicity for c= lients that don't need the extra security.   I happen to agree with you= but it is Google that needs the convincing, as they have deployed the non c= rypto version.
As with many things getting people to adopt it is the tri= ck.

John B.

On N= ov 9, 2013, at 8:15 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi John,

why not make the more secure option the only one?

regards,
Torsten.



John Bradley <ve7jtb@ve7jtb.com&= gt; schrieb:
With a native app using a captive browser with no malware, only the response= is susceptible to interception, making encrypting the request redundant.In other environments and with some user groups the request's challenge ne= eds to be protected from interception.  This may be more the case in a d= esktop environment where there is less control over the browser.
<= br>
I expect that we will come to two options one unprotected requ= ests and one for protected requests.

To Phil's poin= t this is not about identifying the class of software this is about matching= a response to an instance of software.   
A software st= atement gives you a hint about the class of software but not the instance wi= thout per client registration.

This method gives yo= u the ability to securely return the token to only the instance of the clien= t that requested it without the overhead of per instance dynamic registration.

This is a practical solution to a rea= l problem people are having today, and versions of this are in production no= w.   

Nat and I are trying to document it= so that there can be interoperability rather than every AS doing something d= ifferent.

John B.

On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=20 =20 =20
Hi Nat,

what's the rationale for having different algorithms to produce a code challenges? As this may cause interop issues there should be good reasons to introduce variants.

regards,
Torsten.


Am 19.10.2013 12:15, schrieb Nat Sakimura:
Incorporated the discussion at Berlin meeting and after in the ML. 

Best, 

Nat

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
= Date: 2013/10/19
Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-02.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:        draft-sakimura-oauth-tcse Revision:        02
Title:           OAuth Symmetric Proof o= f Posession for Code Extension
Creation date:   2013-10-19
Group:           Individual Submission<= br> Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-sak= imura-oauth-tcse-02.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse=
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-= oauth-tcse-02

Abstract:
   The OAuth 2.0 public client utilizing authorization= code grant is
   susceptible to the code interception attack.  = This specification
   describe a mechanism that acts as a control against= this threat.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.iet= f.org.

The IETF Secretariat




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
OAuth mailing list
OAuth@i=
etf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= /a>


= --Apple-Mail-DA3BE550-2889-4DCE-AA17-C10C0CCA6E03-- From phil.hunt@oracle.com Sat Nov 9 12:32:23 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A849121E8096 for ; Sat, 9 Nov 2013 12:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.56 X-Spam-Level: X-Spam-Status: No, score=-5.56 tagged_above=-999 required=5 tests=[AWL=-0.358, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUhoV0gYPTXd for ; Sat, 9 Nov 2013 12:32:18 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB8811E80F9 for ; Sat, 9 Nov 2013 12:32:18 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA9KWFkj002122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 9 Nov 2013 20:32:16 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA9KWFtG024649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Nov 2013 20:32:15 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA9KWFa3024646; Sat, 9 Nov 2013 20:32:15 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 09 Nov 2013 12:32:14 -0800 References: <20131019101348.9565.3370.idtracker@ietfa.amsl.com> <527E376C.2010205@lodderstedt.net> <001C64DB-2DD0-4740-8C9A-B7A0445F68CD@ve7jtb.com> <78E2CDE2-D49B-423E-AF13-097660FFB03F@ve7jtb.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-C2731F7E-67B4-4ADA-8FAD-5C793DE6C7B7 Content-Transfer-Encoding: 7bit Message-Id: <81C0B993-31B3-4591-8C91-9214AD90B26F@oracle.com> X-Mailer: iPhone Mail (11B511) From: Phil Hunt Date: Sat, 9 Nov 2013 12:32:09 -0800 To: Torsten Lodderstedt X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 20:32:23 -0000 --Apple-Mail-C2731F7E-67B4-4ADA-8FAD-5C793DE6C7B7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sounds interesting.=20 I wonder about why one might choose a public model with tcse vs stateless cl= ient reg? =20 Eg. Tcse might be more important for transient clients.=20 Phil > On Nov 9, 2013, at 12:27, Torsten Lodderstedt wr= ote: >=20 > Hi, >=20 > thanks for the explanation. Seems there is the simpler option sufficient t= o solve the original problem but it's not secure enough to be a general solu= tion.=20 >=20 > Regarding implementation: The simpler option requires the developer to cre= ate a value of reasonable randomness and the second additionally requires to= calculate the SHA correctly. I'm afraid client developers will have trouble= implementing it correctly. That's why the idea of OAuth always was to push c= omplexity to the server implementation. >=20 > While thinking about your proposal, I remembered a potential alternative. W= e initially discussed usage of dynamically issued client id/secrets (dyn. cl= ient registration) in order to mitigate the threat. This has two advantages:= > - it utilizes general OAuth functionality > - usage of client credentials is easy from a client developers perspective= >=20 > This idea was originally rejected due to the potential implications on sca= lability. The assumption was, potentially billions of client instances could= not be managed by the AS in a reasonable way. Based on the outcome of the l= atest discussions around dynamic registration, we now know how to implement r= egistration in a stateless way using client secrets as self-contained tokens= . So this should not be a scalability issue any longer. >=20 > Should we reconsider this alternative? >=20 > regards, > Torsten. >=20 >> Am 09.11.2013 um 19:04 schrieb Nat Sakimura : >>=20 >> And adding to it, it is Google's application team that needs to be persua= ded. As usual, persuading application people to use crypto is hard. We have t= o strike a point that is acceptable to them as well as being somewhat sensib= le security-wise. Having option to bump up the security is important as a fu= ture migration path as well, hence the current design.=20 >>=20 >> =3Dnat via iPhone >>=20 >> Nov 10, 2013 1:42=E3=80=81John Bradley =E3=81=AE=E3=83= =A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8: >>=20 >>> Simplicity for clients that don't need the extra security. I happen to= agree with you but it is Google that needs the convincing, as they have dep= loyed the non crypto version. >>> As with many things getting people to adopt it is the trick. >>>=20 >>> John B. >>>=20 >>>> On Nov 9, 2013, at 8:15 AM, Torsten Lodderstedt wrote: >>>>=20 >>>> Hi John, >>>>=20 >>>> why not make the more secure option the only one? >>>>=20 >>>> regards, >>>> Torsten. >>>>=20 >>>>=20 >>>>=20 >>>> John Bradley schrieb: >>>>>=20 >>>>> With a native app using a captive browser with no malware, only the re= sponse is susceptible to interception, making encrypting the request redunda= nt. >>>>> In other environments and with some user groups the request's challeng= e needs to be protected from interception. This may be more the case in a d= esktop environment where there is less control over the browser. >>>>>=20 >>>>> I expect that we will come to two options one unprotected requests and= one for protected requests. >>>>>=20 >>>>> To Phil's point this is not about identifying the class of software th= is is about matching a response to an instance of software. =20 >>>>> A software statement gives you a hint about the class of software but n= ot the instance without per client registration. >>>>>=20 >>>>> This method gives you the ability to securely return the token to only= the instance of the client that requested it without the overhead of per in= stance dynamic registration. >>>>>=20 >>>>> This is a practical solution to a real problem people are having today= , and versions of this are in production now. =20 >>>>>=20 >>>>> Nat and I are trying to document it so that there can be interoperabil= ity rather than every AS doing something different. >>>>>=20 >>>>> John B. >>>>>=20 >>>>>> On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt wrote: >>>>>>=20 >>>>>> Hi Nat, >>>>>>=20 >>>>>> what's the rationale for having different algorithms to produce a cod= e challenges? As this may cause interop issues there should be good reasons t= o introduce variants. >>>>>>=20 >>>>>> regards, >>>>>> Torsten. >>>>>>=20 >>>>>>=20 >>>>>> Am 19.10.2013 12:15, schrieb Nat Sakimura: >>>>>>> Incorporated the discussion at Berlin meeting and after in the ML.=20= >>>>>>>=20 >>>>>>> Best,=20 >>>>>>>=20 >>>>>>> Nat >>>>>>>=20 >>>>>>> ---------- Forwarded message ---------- >>>>>>> From: >>>>>>> Date: 2013/10/19 >>>>>>> Subject: New Version Notification for draft-sakimura-oauth-tcse-02.t= xt >>>>>>> To: Nat Sakimura , John Bradley , Naveen Agarwal >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> A new version of I-D, draft-sakimura-oauth-tcse-02.txt >>>>>>> has been successfully submitted by Nat Sakimura and posted to the >>>>>>> IETF repository. >>>>>>>=20 >>>>>>> Filename: draft-sakimura-oauth-tcse >>>>>>> Revision: 02 >>>>>>> Title: OAuth Symmetric Proof of Posession for Code Extensi= on >>>>>>> Creation date: 2013-10-19 >>>>>>> Group: Individual Submission >>>>>>> Number of pages: 8 >>>>>>> URL: http://www.ietf.org/internet-drafts/draft-sakimura-= oauth-tcse-02.txt >>>>>>> Status: http://datatracker.ietf.org/doc/draft-sakimura-oaut= h-tcse >>>>>>> Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-tcs= e-02 >>>>>>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-o= auth-tcse-02 >>>>>>>=20 >>>>>>> Abstract: >>>>>>> The OAuth 2.0 public client utilizing authorization code grant is= >>>>>>> susceptible to the code interception attack. This specification >>>>>>> describe a mechanism that acts as a control against this threat. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Please note that it may take a couple of minutes from the time of su= bmission >>>>>>> until the htmlized version and diff are available at tools.ietf.org.= >>>>>>>=20 >>>>>>> The IETF Secretariat >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> --=20 >>>>>>> Nat Sakimura (=3Dnat) >>>>>>> Chairman, OpenID Foundation >>>>>>> http://nat.sakimura.org/ >>>>>>> @_nat_en >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-C2731F7E-67B4-4ADA-8FAD-5C793DE6C7B7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Sounds interesting. 
I wonder about why one might choose a public model with tcse vs= stateless client reg?  

Eg. Tcse might be mor= e important for transient clients. 

Phil
Hi,

thanks for the explanation. Se= ems there is the simpler option sufficient to solve the original problem but= it's not secure enough to be a general solution. 

=
Regarding implementation: The simpler option requires the developer to c= reate a value of reasonable randomness and the second additionally requires t= o calculate the SHA correctly. I'm afraid client developers will have troubl= e implementing it correctly. That's why the idea of OAuth always was to push= complexity to the server implementation.

While thi= nking about your proposal, I remembered a potential alternative. We initiall= y discussed usage of dynamically issued client id/secrets (dyn. client regis= tration) in order to mitigate the threat. This has two advantages:
- it utilizes general OAuth functionality
- usage of client crede= ntials is easy from a client developers perspective

This idea was originally rejected due to the potential implications on scal= ability. The assumption was, potentially billions of client instances could n= ot be managed by the AS in a reasonable way. Based on the outcome of the lat= est discussions around dynamic registration, we now know how to implement re= gistration in a stateless way using client secrets as self-contained tokens.= So this should not be a scalability issue any longer.

<= div>Should we reconsider this alternative?

regards,=
Torsten.

Am 09.11.2013 um 19:04 schrieb Nat Sakimur= a <sakimura@gmail.com>:
<= br>
And adding to it, it is Google's a= pplication team that needs to be persuaded. As usual, persuading application= people to use crypto is hard. We have to strike a point that is acceptable t= o them as well as being somewhat sensible security-wise. Having option to bu= mp up the security is important as a future migration path as well, hence th= e current design. 

=3Dnat via iPhone

Nov 10, 2013 1= :42=E3=80=81John Bradley <ve7jtb@ve7= jtb.com> =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:
<= br>
Simplicity for clients that don't nee= d the extra security.   I happen to agree with you but it is Google tha= t needs the convincing, as they have deployed the non crypto version.
As= with many things getting people to adopt it is the trick.

John B.

On Nov 9, 2013, at 8:15 A= M, Torsten Lodderstedt <torste= n@lodderstedt.net> wrote:

Hi John,

why not make the more secure option the only one?

regards,
Torsten.



John Bradley <ve7jtb@ve7jtb.com&= gt; schrieb:
With a native app using a captive browser with no malware, only the response= is susceptible to interception, making encrypting the request redundant.In other environments and with some user groups the request's challenge ne= eds to be protected from interception.  This may be more the case in a d= esktop environment where there is less control over the browser.
<= br>
I expect that we will come to two options one unprotected requ= ests and one for protected requests.

To Phil's poin= t this is not about identifying the class of software this is about matching= a response to an instance of software.   
A software st= atement gives you a hint about the class of software but not the instance wi= thout per client registration.

This method gives yo= u the ability to securely return the token to only the instance of the clien= t that requested it without the overhead of per instance dynamic registration.

This is a practical solution to a rea= l problem people are having today, and versions of this are in production no= w.   

Nat and I are trying to document it= so that there can be interoperability rather than every AS doing something d= ifferent.

John B.

On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=20 =20 =20
Hi Nat,

what's the rationale for having different algorithms to produce a code challenges? As this may cause interop issues there should be good reasons to introduce variants.

regards,
Torsten.


Am 19.10.2013 12:15, schrieb Nat Sakimura:
Incorporated the discussion at Berlin meeting and after in the ML. 

Best, 

Nat

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
= Date: 2013/10/19
Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-02.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:        draft-sakimura-oauth-tcse Revision:        02
Title:           OAuth Symmetric Proof o= f Posession for Code Extension
Creation date:   2013-10-19
Group:           Individual Submission<= br> Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-sak= imura-oauth-tcse-02.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse=
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-= oauth-tcse-02

Abstract:
   The OAuth 2.0 public client utilizing authorization= code grant is
   susceptible to the code interception attack.  = This specification
   describe a mechanism that acts as a control against= this threat.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.iet= f.org.

The IETF Secretariat




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
OAuth mailing list
OAuth@i=
etf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= /a>


= --Apple-Mail-C2731F7E-67B4-4ADA-8FAD-5C793DE6C7B7-- From ve7jtb@ve7jtb.com Sat Nov 9 15:13:26 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A947A21F9F6F for ; Sat, 9 Nov 2013 15:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sk2RMAeW85jE for ; Sat, 9 Nov 2013 15:13:22 -0800 (PST) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by ietfa.amsl.com (Postfix) with ESMTP id 32E2E21F9F50 for ; Sat, 9 Nov 2013 15:13:21 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id rd3so858211pab.8 for ; Sat, 09 Nov 2013 15:13:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=3R8LDeUIeXBsHLE9jgb+PYyKeAGBSHgzhnNKA1EHv54=; b=EFwSt52FyTmjCg8Jw2287erfihUbZ1x2Z6jvvJO3mHY8krGloGvsFll6KbmK7xGDM0 0HxCrg1yRCU1eiWs87tNunmTPCnDQUAuo+dGxCJ5M2GjFYR05EspRgktaQeHcJVrsO2j XQTJD+Bqa6RgBJpcFsFWijftWN4WolUMNC8qN4RFtOk5YboRmTRPMvh2tpwpiHkqwlPC PQAm9RQHFg590AueKyCDZXDgF9UZ20/AginTzlXK6oK/6xUfwswZWL5j5VDGOD/Xc7cc 03iZiCtnEV5HvHqCYwK4/8GnZ0nAN1OvRGkYDZQlvsLHWrvnI/XCYQZAb4jsiNNGyPKg swfw== X-Gm-Message-State: ALoCoQlQSw6C9ljGy32UmSTiDkA+fqaDirzy9lhLI+3l8AWjbHc1L+fR671O8FoXCwEToYpDToNm X-Received: by 10.66.102.66 with SMTP id fm2mr23162224pab.94.1384038801558; Sat, 09 Nov 2013 15:13:21 -0800 (PST) Received: from [192.168.111.113] (S01060014bf06f566.vc.shawcable.net. [24.84.116.148]) by mx.google.com with ESMTPSA id gh3sm20879944pbb.2.2013.11.09.15.12.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Nov 2013 15:13:19 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_6398AE86-630F-4B12-A97D-2131238DF7AC"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: John Bradley In-Reply-To: <81C0B993-31B3-4591-8C91-9214AD90B26F@oracle.com> Date: Sat, 9 Nov 2013 15:11:55 -0800 Message-Id: References: <20131019101348.9565.3370.idtracker@ietfa.amsl.com> <527E376C.2010205@lodderstedt.net> <001C64DB-2DD0-4740-8C9A-B7A0445F68CD@ve7jtb.com> <78E2CDE2-D49B-423E-AF13-097660FFB03F@ve7jtb.com> <81C0B993-31B3-4591-8C91-9214AD90B26F@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1822) Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 23:13:26 -0000 --Apple-Mail=_6398AE86-630F-4B12-A97D-2131238DF7AC Content-Type: multipart/alternative; boundary="Apple-Mail=_5EE9EFF1-E05A-4928-A759-CD1BA55A6A50" --Apple-Mail=_5EE9EFF1-E05A-4928-A759-CD1BA55A6A50 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes tcse is a way to use the code flow without per instance = registration, and better security than a plain public client. =20 Not every instance needs to needs registered as long as the redirect_uri = is constant.=20 There is however a difference in how grants are treated then you have = multiple instances with the same client_id. If you want all copies of a app that the user has installed across = devices to have the same grants then use one client_id and tcse. If you want the grants to be separate so that one instance has RW and = the other RO scopes for example then you need dynamic client = registration or to re-confirm all scopes each time and not prompt only = for new scopes for the client. So there are legitimate reasons for = doing both. John B. On Nov 9, 2013, at 12:32 PM, Phil Hunt wrote: > Sounds interesting.=20 >=20 > I wonder about why one might choose a public model with tcse vs = stateless client reg? =20 >=20 > Eg. Tcse might be more important for transient clients.=20 >=20 > Phil >=20 > On Nov 9, 2013, at 12:27, Torsten Lodderstedt = wrote: >=20 >> Hi, >>=20 >> thanks for the explanation. Seems there is the simpler option = sufficient to solve the original problem but it's not secure enough to = be a general solution.=20 >>=20 >> Regarding implementation: The simpler option requires the developer = to create a value of reasonable randomness and the second additionally = requires to calculate the SHA correctly. I'm afraid client developers = will have trouble implementing it correctly. That's why the idea of = OAuth always was to push complexity to the server implementation. >>=20 >> While thinking about your proposal, I remembered a potential = alternative. We initially discussed usage of dynamically issued client = id/secrets (dyn. client registration) in order to mitigate the threat. = This has two advantages: >> - it utilizes general OAuth functionality >> - usage of client credentials is easy from a client developers = perspective >>=20 >> This idea was originally rejected due to the potential implications = on scalability. The assumption was, potentially billions of client = instances could not be managed by the AS in a reasonable way. Based on = the outcome of the latest discussions around dynamic registration, we = now know how to implement registration in a stateless way using client = secrets as self-contained tokens. So this should not be a scalability = issue any longer. >>=20 >> Should we reconsider this alternative? >>=20 >> regards, >> Torsten. >>=20 >> Am 09.11.2013 um 19:04 schrieb Nat Sakimura : >>=20 >>> And adding to it, it is Google's application team that needs to be = persuaded. As usual, persuading application people to use crypto is = hard. We have to strike a point that is acceptable to them as well as = being somewhat sensible security-wise. Having option to bump up the = security is important as a future migration path as well, hence the = current design.=20 >>>=20 >>> =3Dnat via iPhone >>>=20 >>> Nov 10, 2013 1:42=E3=80=81John Bradley = =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8: >>>=20 >>>> Simplicity for clients that don't need the extra security. I = happen to agree with you but it is Google that needs the convincing, as = they have deployed the non crypto version. >>>> As with many things getting people to adopt it is the trick. >>>>=20 >>>> John B. >>>>=20 >>>> On Nov 9, 2013, at 8:15 AM, Torsten Lodderstedt = wrote: >>>>=20 >>>>> Hi John, >>>>>=20 >>>>> why not make the more secure option the only one? >>>>>=20 >>>>> regards, >>>>> Torsten. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> John Bradley schrieb: >>>>> With a native app using a captive browser with no malware, only = the response is susceptible to interception, making encrypting the = request redundant. >>>>> In other environments and with some user groups the request's = challenge needs to be protected from interception. This may be more the = case in a desktop environment where there is less control over the = browser. >>>>>=20 >>>>> I expect that we will come to two options one unprotected requests = and one for protected requests. >>>>>=20 >>>>> To Phil's point this is not about identifying the class of = software this is about matching a response to an instance of software. =20= >>>>> A software statement gives you a hint about the class of software = but not the instance without per client registration. >>>>>=20 >>>>> This method gives you the ability to securely return the token to = only the instance of the client that requested it without the overhead = of per instance dynamic registration. >>>>>=20 >>>>> This is a practical solution to a real problem people are having = today, and versions of this are in production now. =20 >>>>>=20 >>>>> Nat and I are trying to document it so that there can be = interoperability rather than every AS doing something different. >>>>>=20 >>>>> John B. >>>>>=20 >>>>> On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt = wrote: >>>>>=20 >>>>>> Hi Nat, >>>>>>=20 >>>>>> what's the rationale for having different algorithms to produce a = code challenges? As this may cause interop issues there should be good = reasons to introduce variants. >>>>>>=20 >>>>>> regards, >>>>>> Torsten. >>>>>>=20 >>>>>>=20 >>>>>> Am 19.10.2013 12:15, schrieb Nat Sakimura: >>>>>>> Incorporated the discussion at Berlin meeting and after in the = ML.=20 >>>>>>>=20 >>>>>>> Best,=20 >>>>>>>=20 >>>>>>> Nat >>>>>>>=20 >>>>>>> ---------- Forwarded message ---------- >>>>>>> From: >>>>>>> Date: 2013/10/19 >>>>>>> Subject: New Version Notification for = draft-sakimura-oauth-tcse-02.txt >>>>>>> To: Nat Sakimura , John Bradley = , Naveen Agarwal >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> A new version of I-D, draft-sakimura-oauth-tcse-02.txt >>>>>>> has been successfully submitted by Nat Sakimura and posted to = the >>>>>>> IETF repository. >>>>>>>=20 >>>>>>> Filename: draft-sakimura-oauth-tcse >>>>>>> Revision: 02 >>>>>>> Title: OAuth Symmetric Proof of Posession for Code = Extension >>>>>>> Creation date: 2013-10-19 >>>>>>> Group: Individual Submission >>>>>>> Number of pages: 8 >>>>>>> URL: = http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt >>>>>>> Status: = http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse >>>>>>> Htmlized: = http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02 >>>>>>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-oauth-tcse-02 >>>>>>>=20 >>>>>>> Abstract: >>>>>>> The OAuth 2.0 public client utilizing authorization code = grant is >>>>>>> susceptible to the code interception attack. This = specification >>>>>>> describe a mechanism that acts as a control against this = threat. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Please note that it may take a couple of minutes from the time = of submission >>>>>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>>>>=20 >>>>>>> The IETF Secretariat >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> --=20 >>>>>>> Nat Sakimura (=3Dnat) >>>>>>> Chairman, OpenID Foundation >>>>>>> http://nat.sakimura.org/ >>>>>>> @_nat_en >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_5EE9EFF1-E05A-4928-A759-CD1BA55A6A50 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes =  tcse is a way to use the code flow without per instance = registration, and better security than a plain public client. =  
Not every instance needs to needs registered as long as the = redirect_uri is constant. 

There is = however a difference in how grants are treated then you have multiple = instances with the same client_id.
If you want all copies of a = app that the user has installed across devices to have the same grants = then use one client_id and tcse.

If you want = the grants to be separate so that one instance has RW and the other RO = scopes for example then you need dynamic client registration or to = re-confirm all scopes each time and not prompt only for new scopes for = the client.   So there are legitimate reasons for doing = both.

John = B.



On Nov 9, 2013, = at 12:32 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:

Sounds = interesting. 

I wonder about why one might = choose a public model with tcse vs stateless client reg? =  

Eg. Tcse might be more important for = transient clients. 

Phil

On Nov 9, 2013, at = 12:27, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

Hi,

thanks for the = explanation. Seems there is the simpler option sufficient to solve the = original problem but it's not secure enough to be a general = solution. 

Regarding implementation: The = simpler option requires the developer to create a value of reasonable = randomness and the second additionally requires to calculate the SHA = correctly. I'm afraid client developers will have trouble implementing = it correctly. That's why the idea of OAuth always was to push complexity = to the server implementation.

While thinking = about your proposal, I remembered a potential alternative. We initially = discussed usage of dynamically issued client id/secrets (dyn. client = registration) in order to mitigate the threat. This has two = advantages:
- it utilizes general OAuth = functionality
- usage of client credentials is easy from a = client developers perspective

This idea was = originally rejected due to the potential implications on scalability. = The assumption was, potentially billions of client instances could not = be managed by the AS in a reasonable way. Based on the outcome of the = latest discussions around dynamic registration, we now know how to = implement registration in a stateless way using client secrets as = self-contained tokens. So this should not be a scalability issue any = longer.

Should we reconsider this = alternative?

regards,
Torsten.

Am 09.11.2013 um 19:04 schrieb Nat Sakimura <sakimura@gmail.com>:

And adding to it, it is = Google's application team that needs to be persuaded. As usual, = persuading application people to use crypto is hard. We have to strike a = point that is acceptable to them as well as being somewhat sensible = security-wise. Having option to bump up the security is important as a = future migration path as well, hence the current = design. 

=3Dnat via iPhone

Nov 10, 2013 = 1:42=E3=80=81John Bradley <ve7jtb@ve7jtb.com> = =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:

Simplicity for clients that = don't need the extra security.   I happen to agree with you but it = is Google that needs the convincing, as they have deployed the non = crypto version.
As with many things getting people to adopt it is = the trick.

John = B.

On Nov 9, 2013, at 8:15 AM, = Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

Hi = John,

why not make the more secure option the only one?

regards,
Torsten.



John Bradley <ve7jtb@ve7jtb.com> = schrieb:
With a native app using a captive browser with no malware, only the = response is susceptible to interception, making encrypting the request = redundant.
In other environments and with some user groups the = request's challenge needs to be protected from interception.  This = may be more the case in a desktop environment where there is less = control over the browser.

I expect that we will = come to two options one unprotected requests and one for protected = requests.

To Phil's point this is not about = identifying the class of software this is about matching a response to = an instance of software.   
A software statement = gives you a hint about the class of software but not the instance = without per client registration.

This method = gives you the ability to securely return the token to only the instance = of the client that requested it without the overhead of per instance = dynamic registration.

This is a practical solution to a = real problem people are having today, and versions of this are in = production now.   

Nat and I are = trying to document it so that there can be interoperability rather than = every AS doing something different.

John = B.

On Nov 9, 2013, at 5:23 AM, = Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

=20 =20 =20
Hi Nat,

what's the rationale for having different algorithms to produce a code challenges? As this may cause interop issues there should be good reasons to introduce variants.

regards,
Torsten.


Am 19.10.2013 12:15, schrieb Nat Sakimura:
Incorporated the discussion at Berlin meeting and after in the ML. 

Best, 

Nat

---------- Forwarded message ----------
From: <internet-drafts@ietf.org><= /span>
Date: 2013/10/19
Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>= ;, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-02.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:       =  draft-sakimura-oauth-tcse
Revision:        02
Title:           OAuth Symmetric = Proof of Posession for Code Extension
Creation date:   2013-10-19
Group:           Individual = Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-sakimura-oauth= -tcse-02.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcs= e
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02<= /a>
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-oauth-= tcse-02

Abstract:
   The OAuth 2.0 public client utilizing = authorization code grant is
   susceptible to the code interception attack. =  This specification
   describe a mechanism that acts as a control = against this threat.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth

_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


_______________________________________________=
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth
__________________= _____________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_5EE9EFF1-E05A-4928-A759-CD1BA55A6A50-- --Apple-Mail=_6398AE86-630F-4B12-A97D-2131238DF7AC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMTA5MjMxMTU2WjAjBgkqhkiG9w0BCQQxFgQUfze355le mPXuRGW+ZDJ9AXunYVQwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAixI7U/SzyceVrIdp6EP+i8AVeI1o1bh4KkFdTJej 8FibJyJMhAlidytP3ldw0nF1BENgARTYsqg97u4m3ha7K08joha3KoruKmUOHxIehOiavobO/ASN 3t61jqkPrlK8yJ8LFbesxowPpNaDVbv2w8UULxmff8SsG+cpV6Id59CHCKwN4Lvngn40C0NywDEl lfp4YRtQka3hskmgplFZ8tY3Kk++VLUf+n+epPreGpWPD7MtA4ShK9mfdfptVFJf+tnusDWUDXql Xq5LM702pp5x2Y1YuvPpV/BGUClU4bASggWHwRj/w+Z94m+etOd8vlGAnwn7BpZemHoxJt8u5wAA AAAAAA== --Apple-Mail=_6398AE86-630F-4B12-A97D-2131238DF7AC-- From phil.hunt@oracle.com Sat Nov 9 15:46:25 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8438E21F9EE9 for ; Sat, 9 Nov 2013 15:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.752 X-Spam-Level: X-Spam-Status: No, score=-4.752 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIwAyqB2k1fr for ; Sat, 9 Nov 2013 15:46:10 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2649B21E8082 for ; Sat, 9 Nov 2013 15:46:10 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA9Nk8Yp015439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 9 Nov 2013 23:46:09 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA9Nk6OY014737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Nov 2013 23:46:07 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA9Nk6Gf014730; Sat, 9 Nov 2013 23:46:06 GMT Received: from [25.69.154.198] (/24.114.39.51) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 09 Nov 2013 15:46:05 -0800 References: <20131019101348.9565.3370.idtracker@ietfa.amsl.com> <527E376C.2010205@lodderstedt.net> <001C64DB-2DD0-4740-8C9A-B7A0445F68CD@ve7jtb.com> <78E2CDE2-D49B-423E-AF13-097660FFB03F@ve7jtb.com> <81C0B993-31B3-4591-8C91-9214AD90B26F@oracle.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-2EEB6AB4-B0F1-4F62-9ABD-3A3D98AD65B0 Content-Transfer-Encoding: 7bit Message-Id: <92C8BA6D-47A0-44EE-91BD-24BE735120C0@oracle.com> X-Mailer: iPhone Mail (11B511) From: Phil Hunt Date: Sat, 9 Nov 2013 15:45:58 -0800 To: John Bradley X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 23:46:25 -0000 --Apple-Mail-2EEB6AB4-B0F1-4F62-9ABD-3A3D98AD65B0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 How would clients find out? Discovery, docs? Phil > On Nov 9, 2013, at 15:11, John Bradley wrote: >=20 > Yes tcse is a way to use the code flow without per instance registration,= and better security than a plain public client. =20 > Not every instance needs to needs registered as long as the redirect_uri i= s constant.=20 >=20 > There is however a difference in how grants are treated then you have mult= iple instances with the same client_id. > If you want all copies of a app that the user has installed across devices= to have the same grants then use one client_id and tcse. >=20 > If you want the grants to be separate so that one instance has RW and the o= ther RO scopes for example then you need dynamic client registration or to r= e-confirm all scopes each time and not prompt only for new scopes for the cl= ient. So there are legitimate reasons for doing both. >=20 > John B. >=20 >=20 >=20 >> On Nov 9, 2013, at 12:32 PM, Phil Hunt wrote: >>=20 >> Sounds interesting.=20 >>=20 >> I wonder about why one might choose a public model with tcse vs stateless= client reg? =20 >>=20 >> Eg. Tcse might be more important for transient clients.=20 >>=20 >> Phil >>=20 >>> On Nov 9, 2013, at 12:27, Torsten Lodderstedt w= rote: >>>=20 >>> Hi, >>>=20 >>> thanks for the explanation. Seems there is the simpler option sufficient= to solve the original problem but it's not secure enough to be a general so= lution.=20 >>>=20 >>> Regarding implementation: The simpler option requires the developer to c= reate a value of reasonable randomness and the second additionally requires t= o calculate the SHA correctly. I'm afraid client developers will have troubl= e implementing it correctly. That's why the idea of OAuth always was to push= complexity to the server implementation. >>>=20 >>> While thinking about your proposal, I remembered a potential alternative= . We initially discussed usage of dynamically issued client id/secrets (dyn.= client registration) in order to mitigate the threat. This has two advantag= es: >>> - it utilizes general OAuth functionality >>> - usage of client credentials is easy from a client developers perspecti= ve >>>=20 >>> This idea was originally rejected due to the potential implications on s= calability. The assumption was, potentially billions of client instances cou= ld not be managed by the AS in a reasonable way. Based on the outcome of the= latest discussions around dynamic registration, we now know how to implemen= t registration in a stateless way using client secrets as self-contained tok= ens. So this should not be a scalability issue any longer. >>>=20 >>> Should we reconsider this alternative? >>>=20 >>> regards, >>> Torsten. >>>=20 >>>> Am 09.11.2013 um 19:04 schrieb Nat Sakimura : >>>>=20 >>>> And adding to it, it is Google's application team that needs to be pers= uaded. As usual, persuading application people to use crypto is hard. We hav= e to strike a point that is acceptable to them as well as being somewhat sen= sible security-wise. Having option to bump up the security is important as a= future migration path as well, hence the current design.=20 >>>>=20 >>>> =3Dnat via iPhone >>>>=20 >>>> Nov 10, 2013 1:42=E3=80=81John Bradley =E3=81=AE=E3= =83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8: >>>>=20 >>>>> Simplicity for clients that don't need the extra security. I happen t= o agree with you but it is Google that needs the convincing, as they have de= ployed the non crypto version. >>>>> As with many things getting people to adopt it is the trick. >>>>>=20 >>>>> John B. >>>>>=20 >>>>>> On Nov 9, 2013, at 8:15 AM, Torsten Lodderstedt wrote: >>>>>>=20 >>>>>> Hi John, >>>>>>=20 >>>>>> why not make the more secure option the only one? >>>>>>=20 >>>>>> regards, >>>>>> Torsten. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> John Bradley schrieb: >>>>>>>=20 >>>>>>> With a native app using a captive browser with no malware, only the r= esponse is susceptible to interception, making encrypting the request redund= ant. >>>>>>> In other environments and with some user groups the request's challe= nge needs to be protected from interception. This may be more the case in a= desktop environment where there is less control over the browser. >>>>>>>=20 >>>>>>> I expect that we will come to two options one unprotected requests a= nd one for protected requests. >>>>>>>=20 >>>>>>> To Phil's point this is not about identifying the class of software t= his is about matching a response to an instance of software. =20 >>>>>>> A software statement gives you a hint about the class of software bu= t not the instance without per client registration. >>>>>>>=20 >>>>>>> This method gives you the ability to securely return the token to on= ly the instance of the client that requested it without the overhead of per i= nstance dynamic registration. >>>>>>>=20 >>>>>>> This is a practical solution to a real problem people are having tod= ay, and versions of this are in production now. =20 >>>>>>>=20 >>>>>>> Nat and I are trying to document it so that there can be interoperab= ility rather than every AS doing something different. >>>>>>>=20 >>>>>>> John B. >>>>>>>=20 >>>>>>>> On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt wrote: >>>>>>>>=20 >>>>>>>> Hi Nat, >>>>>>>>=20 >>>>>>>> what's the rationale for having different algorithms to produce a = code challenges? As this may cause interop issues there should be good re= asons to introduce variants. >>>>>>>>=20 >>>>>>>> regards, >>>>>>>> Torsten. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Am 19.10.2013 12:15, schrieb Nat Sakimura: >>>>>>>>> Incorporated the discussion at Berlin meeting and after in the ML.= =20 >>>>>>>>>=20 >>>>>>>>> Best,=20 >>>>>>>>>=20 >>>>>>>>> Nat >>>>>>>>>=20 >>>>>>>>> ---------- Forwarded message ---------- >>>>>>>>> From: >>>>>>>>> Date: 2013/10/19 >>>>>>>>> Subject: New Version Notification for draft-sakimura-oauth-tcse-02= .txt >>>>>>>>> To: Nat Sakimura , John Bradley , Naveen Agarwal >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> A new version of I-D, draft-sakimura-oauth-tcse-02.txt >>>>>>>>> has been successfully submitted by Nat Sakimura and posted to the >>>>>>>>> IETF repository. >>>>>>>>>=20 >>>>>>>>> Filename: draft-sakimura-oauth-tcse >>>>>>>>> Revision: 02 >>>>>>>>> Title: OAuth Symmetric Proof of Posession for Code Exten= sion >>>>>>>>> Creation date: 2013-10-19 >>>>>>>>> Group: Individual Submission >>>>>>>>> Number of pages: 8 >>>>>>>>> URL: http://www.ietf.org/internet-drafts/draft-sakimur= a-oauth-tcse-02.txt >>>>>>>>> Status: http://datatracker.ietf.org/doc/draft-sakimura-oa= uth-tcse >>>>>>>>> Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-t= cse-02 >>>>>>>>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura= -oauth-tcse-02 >>>>>>>>>=20 >>>>>>>>> Abstract: >>>>>>>>> The OAuth 2.0 public client utilizing authorization code grant i= s >>>>>>>>> susceptible to the code interception attack. This specificatio= n >>>>>>>>> describe a mechanism that acts as a control against this threat= . >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Please note that it may take a couple of minutes from the time of s= ubmission >>>>>>>>> until the htmlized version and diff are available at tools.ietf.or= g. >>>>>>>>>=20 >>>>>>>>> The IETF Secretariat >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> --=20 >>>>>>>>> Nat Sakimura (=3Dnat) >>>>>>>>> Chairman, OpenID Foundation >>>>>>>>> http://nat.sakimura.org/ >>>>>>>>> @_nat_en >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-2EEB6AB4-B0F1-4F62-9ABD-3A3D98AD65B0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1

How would c= lients find out? Discovery, docs?

Phil

On Nov 9, 2013, a= t 15:11, John Bradley <ve7jtb@ve7jtb= .com> wrote:

Yes  tcse is a way to use the code flow without per instance reg= istration, and better security than a plain public client.  
Not ev= ery instance needs to needs registered as long as the redirect_uri is consta= nt. 

There is however a difference in how gran= ts are treated then you have multiple instances with the same client_id.
If you want all copies of a app that the user has installed across de= vices to have the same grants then use one client_id and tcse.
If you want the grants to be separate so that one instance has R= W and the other RO scopes for example then you need dynamic client registrat= ion or to re-confirm all scopes each time and not prompt only for new scopes= for the client.   So there are legitimate reasons for doing both.

John B.



On Nov 9, 2013, at 12:32 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Sounds inte= resting. 

I wonder about why one might choose a= public model with tcse vs stateless client reg?  

=
Eg. Tcse might be more important for transient clients. 

Ph= il

On Nov 9, 2013, at 12:27, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
<= br>
Hi,

thanks for= the explanation. Seems there is the simpler option sufficient to solve the o= riginal problem but it's not secure enough to be a general solution. 

Regarding implementation: The simpler option require= s the developer to create a value of reasonable randomness and the second ad= ditionally requires to calculate the SHA correctly. I'm afraid client develo= pers will have trouble implementing it correctly. That's why the idea of OAu= th always was to push complexity to the server implementation.
While thinking about your proposal, I remembered a potential alt= ernative. We initially discussed usage of dynamically issued client id/secre= ts (dyn. client registration) in order to mitigate the threat. This has two a= dvantages:
- it utilizes general OAuth functionality
- u= sage of client credentials is easy from a client developers perspective

This idea was originally rejected due to the potential i= mplications on scalability. The assumption was, potentially billions of clie= nt instances could not be managed by the AS in a reasonable way. Based on th= e outcome of the latest discussions around dynamic registration, we now know= how to implement registration in a stateless way using client secrets as se= lf-contained tokens. So this should not be a scalability issue any longer.

Should we reconsider this alternative?
regards,
Torsten.

Am 09.11.2013 um 19:04= schrieb Nat Sakimura <sakimura@gma= il.com>:

And adding to it, i= t is Google's application team that needs to be persuaded. As usual, persuad= ing application people to use crypto is hard. We have to strike a point that= is acceptable to them as well as being somewhat sensible security-wise. Hav= ing option to bump up the security is important as a future migration path a= s well, hence the current design. 

=3Dnat via iPhone
<= br>Nov 10, 2013 1:42=E3=80=81John Bradley <ve7jtb@ve7jtb.com> =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC= =E3=82=B8:

Simplicity for clients that= don't need the extra security.   I happen to agree with you but it is G= oogle that needs the convincing, as they have deployed the non crypto versio= n.
As with many things getting people to adopt it is the trick.

John B.

On Nov 9, 2013, a= t 8:15 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi John,
why not make the more secure option the only one?

regards,
Torsten.



John Bradley <ve7jtb@ve7jtb.com&= gt; schrieb:
With a native app using a captive browser with no malware, only the response= is susceptible to interception, making encrypting the request redundant.In other environments and with some user groups the request's challenge ne= eds to be protected from interception.  This may be more the case in a d= esktop environment where there is less control over the browser.
<= br>
I expect that we will come to two options one unprotected requ= ests and one for protected requests.

To Phil's poin= t this is not about identifying the class of software this is about matching= a response to an instance of software.   
A software st= atement gives you a hint about the class of software but not the instance wi= thout per client registration.

This method gives yo= u the ability to securely return the token to only the instance of the clien= t that requested it without the overhead of per instance dynamic registration.

This is a practical solution to a rea= l problem people are having today, and versions of this are in production no= w.   

Nat and I are trying to document it= so that there can be interoperability rather than every AS doing something d= ifferent.

John B.

On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=20 =20 =20
Hi Nat,

what's the rationale for having different algorithms to produce a code challenges? As this may cause interop issues there should be good reasons to introduce variants.

regards,
Torsten.


Am 19.10.2013 12:15, schrieb Nat Sakimura:
Incorporated the discussion at Berlin meeting and after in the ML. 

Best, 

Nat

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
= Date: 2013/10/19
Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-02.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:        draft-sakimura-oauth-tcse Revision:        02
Title:           OAuth Symmetric Proof o= f Posession for Code Extension
Creation date:   2013-10-19
Group:           Individual Submission<= br> Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-sak= imura-oauth-tcse-02.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse=
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-= oauth-tcse-02

Abstract:
   The OAuth 2.0 public client utilizing authorization= code grant is
   susceptible to the code interception attack.  = This specification
   describe a mechanism that acts as a control against= this threat.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.iet= f.org.

The IETF Secretariat




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
OAuth mailing list
OAuth@i=
etf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= /a>


_______________________________________________
OAu= th mailing list
OAuth@ietf= .org
https://www.ietf.org/mailman/listinfo/oauth
= _______________________________________________
OAuth mailing list<= br>OAuth@ietf.org
https://www.ietf.org/mailman/listinfo= /oauth

= --Apple-Mail-2EEB6AB4-B0F1-4F62-9ABD-3A3D98AD65B0-- From torsten@lodderstedt.net Sun Nov 10 00:58:11 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134AA11E8143 for ; Sun, 10 Nov 2013 00:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95qcJ4DipPym for ; Sun, 10 Nov 2013 00:58:06 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.94]) by ietfa.amsl.com (Postfix) with ESMTP id 1B63A21F9DC9 for ; Sun, 10 Nov 2013 00:58:05 -0800 (PST) Received: from [79.253.35.208] (helo=android-7beef8dd1ccd7199.fritz.box) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1VfQqJ-0002kn-AJ; Sun, 10 Nov 2013 09:58:03 +0100 User-Agent: K-9 Mail for Android In-Reply-To: References: <20131019101348.9565.3370.idtracker@ietfa.amsl.com> <527E376C.2010205@lodderstedt.net> <001C64DB-2DD0-4740-8C9A-B7A0445F68CD@ve7jtb.com> <78E2CDE2-D49B-423E-AF13-097660FFB03F@ve7jtb.com> <81C0B993-31B3-4591-8C91-9214AD90B26F@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----74ZCJE1FORAPD2K696QSLC5LQFN6BT" From: Torsten Lodderstedt Date: Sun, 10 Nov 2013 09:57:57 +0100 To: John Bradley ,Phil Hunt Message-ID: <2086f475-8ad1-4263-93c4-33a8e47e51de@email.android.com> X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 08:58:11 -0000 ------74ZCJE1FORAPD2K696QSLC5LQFN6BT Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit One can relate all instances of the same app using an initial access token. So doing per client instance registration does not preclude to manage grants per app. John Bradley schrieb: >Yes tcse is a way to use the code flow without per instance >registration, and better security than a plain public client. >Not every instance needs to needs registered as long as the >redirect_uri is constant. > >There is however a difference in how grants are treated then you have >multiple instances with the same client_id. >If you want all copies of a app that the user has installed across >devices to have the same grants then use one client_id and tcse. > >If you want the grants to be separate so that one instance has RW and >the other RO scopes for example then you need dynamic client >registration or to re-confirm all scopes each time and not prompt only >for new scopes for the client. So there are legitimate reasons for >doing both. > >John B. > > > >On Nov 9, 2013, at 12:32 PM, Phil Hunt wrote: > >> Sounds interesting. >> >> I wonder about why one might choose a public model with tcse vs >stateless client reg? >> >> Eg. Tcse might be more important for transient clients. >> >> Phil >> >> On Nov 9, 2013, at 12:27, Torsten Lodderstedt > wrote: >> >>> Hi, >>> >>> thanks for the explanation. Seems there is the simpler option >sufficient to solve the original problem but it's not secure enough to >be a general solution. >>> >>> Regarding implementation: The simpler option requires the developer >to create a value of reasonable randomness and the second additionally >requires to calculate the SHA correctly. I'm afraid client developers >will have trouble implementing it correctly. That's why the idea of >OAuth always was to push complexity to the server implementation. >>> >>> While thinking about your proposal, I remembered a potential >alternative. We initially discussed usage of dynamically issued client >id/secrets (dyn. client registration) in order to mitigate the threat. >This has two advantages: >>> - it utilizes general OAuth functionality >>> - usage of client credentials is easy from a client developers >perspective >>> >>> This idea was originally rejected due to the potential implications >on scalability. The assumption was, potentially billions of client >instances could not be managed by the AS in a reasonable way. Based on >the outcome of the latest discussions around dynamic registration, we >now know how to implement registration in a stateless way using client >secrets as self-contained tokens. So this should not be a scalability >issue any longer. >>> >>> Should we reconsider this alternative? >>> >>> regards, >>> Torsten. >>> >>> Am 09.11.2013 um 19:04 schrieb Nat Sakimura : >>> >>>> And adding to it, it is Google's application team that needs to be >persuaded. As usual, persuading application people to use crypto is >hard. We have to strike a point that is acceptable to them as well as >being somewhat sensible security-wise. Having option to bump up the >security is important as a future migration path as well, hence the >current design. >>>> >>>> =nat via iPhone >>>> >>>> Nov 10, 2013 1:42、John Bradley のメッセージ: >>>> >>>>> Simplicity for clients that don't need the extra security. I >happen to agree with you but it is Google that needs the convincing, as >they have deployed the non crypto version. >>>>> As with many things getting people to adopt it is the trick. >>>>> >>>>> John B. >>>>> >>>>> On Nov 9, 2013, at 8:15 AM, Torsten Lodderstedt > wrote: >>>>> >>>>>> Hi John, >>>>>> >>>>>> why not make the more secure option the only one? >>>>>> >>>>>> regards, >>>>>> Torsten. >>>>>> >>>>>> >>>>>> >>>>>> John Bradley schrieb: >>>>>> With a native app using a captive browser with no malware, only >the response is susceptible to interception, making encrypting the >request redundant. >>>>>> In other environments and with some user groups the request's >challenge needs to be protected from interception. This may be more >the case in a desktop environment where there is less control over the >browser. >>>>>> >>>>>> I expect that we will come to two options one unprotected >requests and one for protected requests. >>>>>> >>>>>> To Phil's point this is not about identifying the class of >software this is about matching a response to an instance of software. > >>>>>> A software statement gives you a hint about the class of software >but not the instance without per client registration. >>>>>> >>>>>> This method gives you the ability to securely return the token to >only the instance of the client that requested it without the overhead >of per instance dynamic registration. >>>>>> >>>>>> This is a practical solution to a real problem people are having >today, and versions of this are in production now. >>>>>> >>>>>> Nat and I are trying to document it so that there can be >interoperability rather than every AS doing something different. >>>>>> >>>>>> John B. >>>>>> >>>>>> On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt > wrote: >>>>>> >>>>>>> Hi Nat, >>>>>>> >>>>>>> what's the rationale for having different algorithms to produce >a code challenges? As this may cause interop issues there should be >good reasons to introduce variants. >>>>>>> >>>>>>> regards, >>>>>>> Torsten. >>>>>>> >>>>>>> >>>>>>> Am 19.10.2013 12:15, schrieb Nat Sakimura: >>>>>>>> Incorporated the discussion at Berlin meeting and after in the >ML. >>>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> Nat >>>>>>>> >>>>>>>> ---------- Forwarded message ---------- >>>>>>>> From: >>>>>>>> Date: 2013/10/19 >>>>>>>> Subject: New Version Notification for >draft-sakimura-oauth-tcse-02.txt >>>>>>>> To: Nat Sakimura , John Bradley >, Naveen Agarwal >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> A new version of I-D, draft-sakimura-oauth-tcse-02.txt >>>>>>>> has been successfully submitted by Nat Sakimura and posted to >the >>>>>>>> IETF repository. >>>>>>>> >>>>>>>> Filename: draft-sakimura-oauth-tcse >>>>>>>> Revision: 02 >>>>>>>> Title: OAuth Symmetric Proof of Posession for Code >Extension >>>>>>>> Creation date: 2013-10-19 >>>>>>>> Group: Individual Submission >>>>>>>> Number of pages: 8 >>>>>>>> URL: >http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt >>>>>>>> Status: >http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse >>>>>>>> Htmlized: >http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02 >>>>>>>> Diff: >http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-tcse-02 >>>>>>>> >>>>>>>> Abstract: >>>>>>>> The OAuth 2.0 public client utilizing authorization code >grant is >>>>>>>> susceptible to the code interception attack. This >specification >>>>>>>> describe a mechanism that acts as a control against this >threat. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Please note that it may take a couple of minutes from the time >of submission >>>>>>>> until the htmlized version and diff are available at >tools.ietf.org. >>>>>>>> >>>>>>>> The IETF Secretariat >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Nat Sakimura (=nat) >>>>>>>> Chairman, OpenID Foundation >>>>>>>> http://nat.sakimura.org/ >>>>>>>> @_nat_en >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth ------74ZCJE1FORAPD2K696QSLC5LQFN6BT Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit One can relate all instances of the same app using an initial access token. So doing per client instance registration does not preclude to manage grants per app.



John Bradley <ve7jtb@ve7jtb.com> schrieb:
Yes  tcse is a way to use the code flow without per instance registration, and better security than a plain public client.  
Not every instance needs to needs registered as long as the redirect_uri is constant. 

There is however a difference in how grants are treated then you have multiple instances with the same client_id.
If you want all copies of a app that the user has installed across devices to have the same grants then use one client_id and tcse.

If you want the grants to be separate so that one instance has RW and the other RO scopes for example then you need dynamic client registration or to re-confirm all scopes each time and not prompt only for new scopes for the client.   So there are legitimate reasons for doing both.

John B.



On Nov 9, 2013, at 12:32 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Sounds interesting. 

I wonder about why one might choose a public model with tcse vs stateless client reg?  

Eg. Tcse might be more important for transient clients. 

Phil

On Nov 9, 2013, at 12:27, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi,

thanks for the explanation. Seems there is the simpler option sufficient to solve the original problem but it's not secure enough to be a general solution. 

Regarding implementation: The simpler option requires the developer to create a value of reasonable randomness and the second additionally requires to calculate the S HA correctly. I'm afraid client developers will have trouble implementing it correctly. That's why the idea of OAuth always was to push complexity to the server implementation.

While thinking about your proposal, I remembered a potential alternative. We initially discussed usage of dynamically issued client id/secrets (dyn. client registration) in order to mitigate the threat. This has two advantages:
- it utilizes general OAuth functionality
- usage of client credentials is easy from a client developers perspective

This idea was originally rejected due to the potential implications on scalability. The assumption was, potentially billions of client instances could not be managed by the AS in a reasonable way. Based on the outcome of the latest discussions around dynamic registration, we now know how to implement registration in a stateless way using client secrets as self-contained tokens. So this should n ot be a scalability issue any longer.

Should we reconsider this alternative?

regards,
Torsten.

Am 09.11.2013 um 19:04 schrieb Nat Sakimura <sakimura@gmail.com>:

And adding to it, it is Google's application team that needs to be persuaded. As usual, persuading application people to use crypto is hard. We have to strike a point that is acceptable to them as well as being somewhat sensible security-wise. Having option to bump up the security is important as a future migration path as well, hence the current design. 

=nat via iPhone

Nov 10, 2013 1:42、John Bradley <ve7jtb@ve7jtb.com> のメッセージ:

Simplicity for clients that don't need the extra security.   I happen to agree with you but it is Google that needs the convincing, as they have deployed the non crypto version.
As with many things getting people to adopt it is the trick.

John B.

On Nov 9, 2013, at 8:15 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi John,

why not make the more secure option the only one?

regards,
Torsten.



John Bradley <ve7jtb@ve7jtb.com> schrieb:
With a native app using a captive browser with no malware, only the response is susceptible to interception, making encrypting the request redundant.
In other environments and with some user groups the request's challenge needs to be protected from interception.  This may be more the case in a desktop environment where there is less control over the browser.

I expect that we will come to two options one unprotected requests and one for protected requests.

To Phil's point this is not about identifying the class of software this is about matching a response to an instance of software.   
A software statement gives you a hint about the class of software but not the instance without per client registration.

This method gives you the ability to securely return the token to only the instance of the client that requested it without the overhead of per instance dynamic registration.

This is a practical solution to a real problem people are having today, and versions of this are in production now.   

Nat and I are trying to document it so that there can be interoperability rather than every AS doing something different.

John B.

On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Nat,

what's the rationale for having different algorithms to produce a code challenges? As this may cause interop issues there should be good reasons to introduce variants.

regards,
Torsten.


Am 19.10.2013 12:15, schrieb Nat Sakimura:
Incorporated the discussion at Berlin meeting and after in the ML. 

Best, 

Nat

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: 2013/10/19
Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-02.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:        draft-sakimura-oauth-tcse
Revision:        02
Title:           OAuth Symmetric Proof of Posession for Code Extension
Creation date:   2013-10-19
Group:           Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-tcse-02

Abstract:
   The OAuth 2.0 public client utilizing authorization code grant is
   susceptible to the code interception attack.  This specification
   describe a mechanism that acts as a control against this threat.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

------74ZCJE1FORAPD2K696QSLC5LQFN6BT-- From ve7jtb@ve7jtb.com Sun Nov 10 08:15:20 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2E011E8126 for ; Sun, 10 Nov 2013 08:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zajKIpFNIin for ; Sun, 10 Nov 2013 08:15:16 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E1C4C11E8109 for ; Sun, 10 Nov 2013 08:15:15 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id rp16so4141330pbb.31 for ; Sun, 10 Nov 2013 08:15:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=AeZr/8g8GLVR5u4/pdySWIoTG0pd7N2xQWly9FXUjbs=; b=Awf41rSXmNereo2Y7AhHJzo3u0SzVjUAEPLwgM+8sVPzvrzbfmSNbKyblGohJCqJ0m MTQDAj1dEGkEn+zSiQM64mfOXyVSjKkcmXOigPjP1XhY6Wkktv7Yo5ismRgg1c0h1vzb b3WjgA0YEaH5Ph9D/eZc39yaPhLpiEMUb0prIm1dy1uYYBIYEoIPil5Iaafid3bGjdo5 BRkpwZ6TSpuNJe1B10Oy+pHq6aUuCowQG7XO1Gbn8zcIvBNPbR4LMYuq3ec9EEXQaSBh GjyaJLIDacZnnMU+1yl0ZBqrfO0wwL0Ygtbfpsrb3xwoJwLjeJNOeNDVg/AjNvC3fzaG ea5Q== X-Gm-Message-State: ALoCoQmUjITApairs1HlaEGwX1Px4qFiLCDD6dz2C4W2aBOaHfdIXB6n4DxXfl7eo5GcBs1nTd5V X-Received: by 10.66.121.68 with SMTP id li4mr26214005pab.33.1384100115423; Sun, 10 Nov 2013 08:15:15 -0800 (PST) Received: from [192.168.6.17] (199-91-80-194.ip.van.radiant.net. [199.91.80.194]) by mx.google.com with ESMTPSA id go4sm25192007pbb.15.2013.11.10.08.15.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Nov 2013 08:15:13 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_7C6CF541-6975-4719-95D4-3FB4A9EEC4EF"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: John Bradley In-Reply-To: <2086f475-8ad1-4263-93c4-33a8e47e51de@email.android.com> Date: Sun, 10 Nov 2013 08:15:10 -0800 Message-Id: <9E18394B-9B3C-4714-9821-5DC47DC5311D@ve7jtb.com> References: <20131019101348.9565.3370.idtracker@ietfa.amsl.com> <527E376C.2010205@lodderstedt.net> <001C64DB-2DD0-4740-8C9A-B7A0445F68CD@ve7jtb.com> <78E2CDE2-D49B-423E-AF13-097660FFB03F@ve7jtb.com> <81C0B993-31B3-4591-8C91-9214AD90B26F@oracle.com> <2086f475-8ad1-4263-93c4-33a8e47e51de@email.android.com> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1822) Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 16:15:20 -0000 --Apple-Mail=_7C6CF541-6975-4719-95D4-3FB4A9EEC4EF Content-Type: multipart/alternative; boundary="Apple-Mail=_602AAFB1-0B9D-4418-B5F2-2B9E89F6CBF0" --Apple-Mail=_602AAFB1-0B9D-4418-B5F2-2B9E89F6CBF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 No certainly you can still manage grants per app class if you are doing = per instance registration. It is however more of a UI challenge if you = don't do per instance registration and you want to manage grants per = instance. I mostly wanted to point out that there are two models that AS use = Twitter as an example give all instances of an application the same = grans and I think even the same access token. (OAuth 1 don't blame me:) = Facebook also treats instances as having consented to the same grants. = That has been used for privilege escalation attacks if you can = impersonate a client. Others try and treat different instances of a app as having separate = grants. =20 There are likely reasons to do both, that is for the AS to decide. Discovery and out of band API documentation around how scopes and grants = are treated would likely be how a developer would find out what the = thing to do is.=20 If the AS supports tcse the client could discover it dynamically and use = it as there is no real downside, though if it is already a confidential = client client it would not add much. The stateless client registration is another way to get similar = protection without adding tcse as an extension, however that is still = more work for the server to implement than tcse. Dynamic client registration + stateless is probably the broader solution = that also covers use-cases if I had to pick just one. John B. On Nov 10, 2013, at 12:57 AM, Torsten Lodderstedt = wrote: > One can relate all instances of the same app using an initial access = token. So doing per client instance registration does not preclude to = manage grants per app. >=20 >=20 >=20 > John Bradley schrieb: > Yes tcse is a way to use the code flow without per instance = registration, and better security than a plain public client. =20 > Not every instance needs to needs registered as long as the = redirect_uri is constant.=20 >=20 > There is however a difference in how grants are treated then you have = multiple instances with the same client_id. > If you want all copies of a app that the user has installed across = devices to have the same grants then use one client_id and tcse. >=20 > If you want the grants to be separate so that one instance has RW and = the other RO scopes for example then you need dynamic client = registration or to re-confirm all scopes each time and not prompt only = for new scopes for the client. So there are legitimate reasons for = doing both. >=20 > John B. >=20 >=20 >=20 > On Nov 9, 2013, at 12:32 PM, Phil Hunt wrote: >=20 >> Sounds interesting.=20 >>=20 >> I wonder about why one might choose a public model with tcse vs = stateless client reg? =20 >>=20 >> Eg. Tcse might be more important for transient clients.=20 >>=20 >> Phil >>=20 >> On Nov 9, 2013, at 12:27, Torsten Lodderstedt = wrote: >>=20 >>> Hi, >>>=20 >>> thanks for the explanation. Seems there is the simpler option = sufficient to solve the original problem but it's not secure enough to = be a general solution.=20 >>>=20 >>> Regarding implementation: The simpler option requires the developer = to create a value of reasonable randomness and the second additionally = requires to calculate the SHA correctly. I'm afraid client developers = will have trouble implementing it correctly. That's why the idea of = OAuth always was to push complexity to the server implementation. >>>=20 >>> While thinking about your proposal, I remembered a potential = alternative. We initially discussed usage of dynamically issued client = id/secrets (dyn. client registration) in order to mitigate the threat. = This has two advantages: >>> - it utilizes general OAuth functionality >>> - usage of client credentials is easy from a client developers = perspective >>>=20 >>> This idea was originally rejected due to the potential implications = on scalability. The assumption was, potentially billions of client = instances could not be managed by the AS in a reasonable way. Based on = the outcome of the latest discussions around dynamic registration, we = now know how to implement registration in a stateless way using client = secrets as self-contained tokens. So this should not be a scalability = issue any longer. >>>=20 >>> Should we reconsider this alternative? >>>=20 >>> regards, >>> Torsten. >>>=20 >>> Am 09.11.2013 um 19:04 schrieb Nat Sakimura : >>>=20 >>>> And adding to it, it is Google's application team that needs to be = persuaded. As usual, persuading application people to use crypto is = hard. We have to strike a point that is acceptable to them as well as = being somewhat sensible security-wise. Having option to bump up the = security is important as a future migration path as well, hence the = current design.=20 >>>>=20 >>>> =3Dnat via iPhone >>>>=20 >>>> Nov 10, 2013 1:42=E3=80=81John Bradley = =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8: >>>>=20 >>>>> Simplicity for clients that don't need the extra security. I = happen to agree with you but it is Google that needs the convincing, as = they have deployed the non crypto version. >>>>> As with many things getting people to adopt it is the trick. >>>>>=20 >>>>> John B. >>>>>=20 >>>>> On Nov 9, 2013, at 8:15 AM, Torsten Lodderstedt = wrote: >>>>>=20 >>>>>> Hi John, >>>>>>=20 >>>>>> why not make the more secure option the only one? >>>>>>=20 >>>>>> regards, >>>>>> Torsten. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> John Bradley schrieb: >>>>>> With a native app using a captive browser with no malware, only = the response is susceptible to interception, making encrypting the = request redundant. >>>>>> In other environments and with some user groups the request's = challenge needs to be protected from interception. This may be more the = case in a desktop environment where there is less control over the = browser. >>>>>>=20 >>>>>> I expect that we will come to two options one unprotected = requests and one for protected requests. >>>>>>=20 >>>>>> To Phil's point this is not about identifying the class of = software this is about matching a response to an instance of software. =20= >>>>>> A software statement gives you a hint about the class of software = but not the instance without per client registration. >>>>>>=20 >>>>>> This method gives you the ability to securely return the token to = only the instance of the client that requested it without the overhead = of per instance dynamic registration. >>>>>>=20 >>>>>> This is a practical solution to a real problem people are having = today, and versions of this are in production now. =20 >>>>>>=20 >>>>>> Nat and I are trying to document it so that there can be = interoperability rather than every AS doing something different. >>>>>>=20 >>>>>> John B. >>>>>>=20 >>>>>> On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt = wrote: >>>>>>=20 >>>>>>> Hi Nat, >>>>>>>=20 >>>>>>> what's the rationale for having different algorithms to produce = a code challenges? As this may cause interop issues there should be good = reasons to introduce variants. >>>>>>>=20 >>>>>>> regards, >>>>>>> Torsten. >>>>>>>=20 >>>>>>>=20 >>>>>>> Am 19.10.2013 12:15, schrieb Nat Sakimura: >>>>>>>> Incorporated the discussion at Berlin meeting and after in the = ML.=20 >>>>>>>>=20 >>>>>>>> Best,=20 >>>>>>>>=20 >>>>>>>> Nat >>>>>>>>=20 >>>>>>>> ---------- Forwarded message ---------- >>>>>>>> From: >>>>>>>> Date: 2013/10/19 >>>>>>>> Subject: New Version Notification for = draft-sakimura-oauth-tcse-02.txt >>>>>>>> To: Nat Sakimura , John Bradley = , Naveen Agarwal >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> A new version of I-D, draft-sakimura-oauth-tcse-02.txt >>>>>>>> has been successfully submitted by Nat Sakimura and posted to = the >>>>>>>> IETF repository. >>>>>>>>=20 >>>>>>>> Filename: draft-sakimura-oauth-tcse >>>>>>>> Revision: 02 >>>>>>>> Title: OAuth Symmetric Proof of Posession for Code = Extension >>>>>>>> Creation date: 2013-10-19 >>>>>>>> Group: Individual Submission >>>>>>>> Number of pages: 8 >>>>>>>> URL: = http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt >>>>>>>> Status: = http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse >>>>>>>> Htmlized: = http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02 >>>>>>>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-oauth-tcse-02 >>>>>>>>=20 >>>>>>>> Abstract: >>>>>>>> The OAuth 2.0 public client utilizing authorization code = grant is >>>>>>>> susceptible to the code interception attack. This = specification >>>>>>>> describe a mechanism that acts as a control against this = threat. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Please note that it may take a couple of minutes from the time = of submission >>>>>>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>>>>>=20 >>>>>>>> The IETF Secretariat >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>> Nat Sakimura (=3Dnat) >>>>>>>> Chairman, OpenID Foundation >>>>>>>> http://nat.sakimura.org/ >>>>>>>> @_nat_en >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_602AAFB1-0B9D-4418-B5F2-2B9E89F6CBF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 No = certainly you can still manage grants per app class if you are doing per = instance registration.   It is however more of a UI challenge if = you don't do per instance registration and you want to manage grants per = instance.

I mostly wanted to point out that there are = two models that AS use Twitter as an example give all instances of an = application the same grans and I think even the same access token. = (OAuth 1 don't blame me:)   Facebook also treats instances as = having consented to the same grants.  That has been used for = privilege escalation attacks if you can impersonate a = client.

Others try and treat different = instances of a app as having separate grants. =   

There are likely reasons to do = both, that is for the AS to decide.

Discovery = and out of band API documentation around how scopes and grants are = treated would likely be how a developer would find out what the thing to = do is. 

If the AS supports tcse the client = could discover it dynamically and use it as there is no real downside, = though if it is already a confidential client client it would not add = much.

The stateless client registration is = another way to get similar protection without adding tcse as an = extension, however that is still more work for the server to implement = than tcse.

Dynamic client registration + = stateless is probably the broader solution that also covers use-cases if = I had to pick just one.

John = B.

On Nov 10, 2013, at 12:57 AM, Torsten = Lodderstedt <torsten@lodderstedt.net> = wrote:

One = can relate all instances of the same app using an initial access token. = So doing per client instance registration does not preclude to manage = grants per app.



John Bradley <ve7jtb@ve7jtb.com> = schrieb:
Yes  tcse is a way to use the code flow without per instance = registration, and better security than a plain public client. =  
Not every instance needs to needs registered as long as the = redirect_uri is constant. 

There is = however a difference in how grants are treated then you have multiple = instances with the same client_id.
If you want all copies of a = app that the user has installed across devices to have the same grants = then use one client_id and tcse.

If you want = the grants to be separate so that one instance has RW and the other RO = scopes for example then you need dynamic client registration or to = re-confirm all scopes each time and not prompt only for new scopes for = the client.   So there are legitimate reasons for doing = both.

John = B.



On Nov 9, 2013, = at 12:32 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:

Sounds = interesting. 

I wonder about why one might = choose a public model with tcse vs stateless client reg? =  

Eg. Tcse might be more important for = transient clients. 

Phil

On Nov 9, 2013, at = 12:27, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

Hi,

thanks for the = explanation. Seems there is the simpler option sufficient to solve the = original problem but it's not secure enough to be a general = solution. 

Regarding implementation: The = simpler option requires the developer to create a value of reasonable = randomness and the second additionally requires to calculate the SHA correctly. I'm afraid client developers will have trouble implementing = it correctly. That's why the idea of OAuth always was to push complexity = to the server implementation.

While thinking = about your proposal, I remembered a potential alternative. We initially = discussed usage of dynamically issued client id/secrets (dyn. client = registration) in order to mitigate the threat. This has two = advantages:
- it utilizes general OAuth = functionality
- usage of client credentials is easy from a = client developers perspective

This idea was = originally rejected due to the potential implications on scalability. = The assumption was, potentially billions of client instances could not = be managed by the AS in a reasonable way. Based on the outcome of the = latest discussions around dynamic registration, we now know how to = implement registration in a stateless way using client secrets as = self-contained tokens. So this should not be a scalability issue any longer.

Should we = reconsider this = alternative?

regards,
Torsten.

Am 09.11.2013 um 19:04 schrieb Nat Sakimura <sakimura@gmail.com>:

And adding to it, it is Google's = application team that needs to be persuaded. As usual, persuading = application people to use crypto is hard. We have to strike a point that = is acceptable to them as well as being somewhat sensible security-wise. = Having option to bump up the security is important as a future migration = path as well, hence the current design. 

=3Dnat via = iPhone

Nov 10, 2013 1:42=E3=80=81John Bradley <ve7jtb@ve7jtb.com> = =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:

Simplicity for clients that don't need the extra = security.   I happen to agree with you but it is Google that needs the convincing, as they have deployed the non crypto = version.
As with many things getting people to adopt it is the = trick.

John = B.

On Nov 9, 2013, at 8:15 AM, = Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

Hi John,

why not make the more secure option the only one?

regards,
Torsten.



John Bradley <ve7jtb@ve7jtb.com> = schrieb:
With a native app using a captive browser with no malware, only the = response is susceptible to interception, making encrypting the request = redundant.
In other environments and with some user groups the = request's challenge needs to be protected from interception.  This = may be more the case in a desktop environment where there is less = control over the browser.

I expect that we will = come to two options one unprotected requests and one for protected = requests.

To Phil's point this is not about = identifying the class of software this is about matching a response to = an instance of software.   
A software statement = gives you a hint about the class of software but not the instance = without per client registration.

This method = gives you the ability to securely return the token to only the instance = of the client that requested it without the overhead of per instance = dynamic registration.

This is a practical solution to a = real problem people are having today, and versions of this are in = production now.   

Nat and I are = trying to document it so that there can be interoperability rather than = every AS doing something different.

John = B.

On Nov 9, 2013, at 5:23 AM, = Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

=20 =20 =20
Hi Nat,

what's the rationale for having different algorithms to produce a code challenges? As this may cause interop issues there should be good reasons to introduce variants.

regards,
Torsten.


Am 19.10.2013 12:15, schrieb Nat Sakimura:
Incorporated the discussion at Berlin meeting and after in the ML. 

Best, 

Nat

---------- Forwarded message ----------
From: <internet-drafts@ietf.org><= /span>
Date: 2013/10/19
Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>= ;, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-02.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:       =  draft-sakimura-oauth-tcse
Revision:        02
Title:           OAuth Symmetric = Proof of Posession for Code Extension
Creation date:   2013-10-19
Group:           Individual = Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-sakimura-oauth= -tcse-02.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcs= e
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02<= /a>
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-oauth-= tcse-02

Abstract:
   The OAuth 2.0 public client utilizing = authorization code grant is
   susceptible to the code interception attack. =  This specification
   describe a mechanism that acts as a control = against this threat.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth

_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


_______________________________________________=
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth
__________________= _____________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


= --Apple-Mail=_602AAFB1-0B9D-4418-B5F2-2B9E89F6CBF0-- --Apple-Mail=_7C6CF541-6975-4719-95D4-3FB4A9EEC4EF Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMTEwMTYxNTEwWjAjBgkqhkiG9w0BCQQxFgQU7v44bNTS gggmLOE/ILkK4nLlo/AwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAcEYs59UCA1FDuVzcfZGwCVYMki1+4W+9PBIgU28o 1Bzk2+6IGwBNiM2q58sw2u1u6HhU4CEKIuy6cqtAxc1+9+8SmAis6j0FQToo+xm1f6CxBKdFmu4C c29hRDkWIE39g+j5OF1f2G8+pE4MDm+SzXFzjnRoT+TmnjQUQEAvO6ooBzE0Cz+yABTMYzyJTXcE sRu3Asw5DA4qTBuX+neE8zfOsIRPB8ud1TeSmIljKAf539nCUPodkunZLGjS8f6yykF4H1bUoMSu mzPZ8iYOj/GtmfeyRk3XTwAg2XF5ciI4SENEdjrHbea9How9c3hJ0x0lTVAplAMQNnwto4ufJQAA AAAAAA== --Apple-Mail=_7C6CF541-6975-4719-95D4-3FB4A9EEC4EF-- From torsten@lodderstedt.net Sun Nov 10 10:33:00 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B6211E8177 for ; Sun, 10 Nov 2013 10:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEGhV1TooVgK for ; Sun, 10 Nov 2013 10:32:56 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by ietfa.amsl.com (Postfix) with ESMTP id 26FD011E8165 for ; Sun, 10 Nov 2013 10:32:54 -0800 (PST) Received: from [79.253.35.208] (helo=[192.168.71.44]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1VfZoT-0002N4-S9; Sun, 10 Nov 2013 19:32:46 +0100 Message-ID: <527FD14F.7050406@lodderstedt.net> Date: Sun, 10 Nov 2013 19:32:47 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: John Bradley References: <20131019101348.9565.3370.idtracker@ietfa.amsl.com> <527E376C.2010205@lodderstedt.net> <001C64DB-2DD0-4740-8C9A-B7A0445F68CD@ve7jtb.com> <78E2CDE2-D49B-423E-AF13-097660FFB03F@ve7jtb.com> <81C0B993-31B3-4591-8C91-9214AD90B26F@oracle.com> <2086f475-8ad1-4263-93c4-33a8e47e51de@email.android.com> <9E18394B-9B3C-4714-9821-5DC47DC5311D@ve7jtb.com> In-Reply-To: <9E18394B-9B3C-4714-9821-5DC47DC5311D@ve7jtb.com> Content-Type: multipart/alternative; boundary="------------050504010101090607000108" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 18:33:00 -0000 This is a multi-part message in MIME format. --------------050504010101090607000108 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit > > Dynamic client registration + stateless is probably the broader > solution that also covers use-cases if I had to pick just one. That's my point. I have to decide what to implement in my service since we need a solution for our (partner) apps. And right now I'm tending more towards dynamic client registration + stateless. In my opinion, it's not only broader but easier to use from a client developer's perspective (that's what I care more about than server-side complexity). regards, Torsten. > > John B. > > On Nov 10, 2013, at 12:57 AM, Torsten Lodderstedt > > wrote: > >> One can relate all instances of the same app using an initial access >> token. So doing per client instance registration does not preclude to >> manage grants per app. >> >> >> >> John Bradley > schrieb: >> >> Yes tcse is a way to use the code flow without per instance >> registration, and better security than a plain public client. >> Not every instance needs to needs registered as long as the >> redirect_uri is constant. >> >> There is however a difference in how grants are treated then you >> have multiple instances with the same client_id. >> If you want all copies of a app that the user has installed >> across devices to have the same grants then use one client_id and >> tcse. >> >> If you want the grants to be separate so that one instance has RW >> and the other RO scopes for example then you need dynamic client >> registration or to re-confirm all scopes each time and not prompt >> only for new scopes for the client. So there are legitimate >> reasons for doing both. >> >> John B. >> >> >> >> On Nov 9, 2013, at 12:32 PM, Phil Hunt > > wrote: >> >>> Sounds interesting. >>> >>> I wonder about why one might choose a public model with tcse vs >>> stateless client reg? >>> >>> Eg. Tcse might be more important for transient clients. >>> >>> Phil >>> >>> On Nov 9, 2013, at 12:27, Torsten Lodderstedt >>> > wrote: >>> >>>> Hi, >>>> >>>> thanks for the explanation. Seems there is the simpler option >>>> sufficient to solve the original problem but it's not secure >>>> enough to be a general solution. >>>> >>>> Regarding implementation: The simpler option requires the >>>> developer to create a value of reasonable randomness and the >>>> second additionally requires to calculate the SHA correctly. >>>> I'm afraid client developers will have trouble implementing it >>>> correctly. That's why the idea of OAuth always was to push >>>> complexity to the server implementation. >>>> >>>> While thinking about your proposal, I remembered a potential >>>> alternative. We initially discussed usage of dynamically issued >>>> client id/secrets (dyn. client registration) in order to >>>> mitigate the threat. This has two advantages: >>>> - it utilizes general OAuth functionality >>>> - usage of client credentials is easy from a client developers >>>> perspective >>>> >>>> This idea was originally rejected due to the potential >>>> implications on scalability. The assumption was, potentially >>>> billions of client instances could not be managed by the AS in >>>> a reasonable way. Based on the outcome of the latest >>>> discussions around dynamic registration, we now know how to >>>> implement registration in a stateless way using client secrets >>>> as self-contained tokens. So this should not be a scalability >>>> issue any longer. >>>> >>>> Should we reconsider this alternative? >>>> >>>> regards, >>>> Torsten. >>>> >>>> Am 09.11.2013 um 19:04 schrieb Nat Sakimura >>> >: >>>> >>>>> And adding to it, it is Google's application team that needs >>>>> to be persuaded. As usual, persuading application people to >>>>> use crypto is hard. We have to strike a point that is >>>>> acceptable to them as well as being somewhat sensible >>>>> security-wise. Having option to bump up the security is >>>>> important as a future migration path as well, hence the >>>>> current design. >>>>> >>>>> =nat via iPhone >>>>> >>>>> Nov 10, 2013 1:42、John Bradley >>>> > のメッセージ: >>>>> >>>>>> Simplicity for clients that don't need the extra security. >>>>>> I happen to agree with you but it is Google that needs the >>>>>> convincing, as they have deployed the non crypto version. >>>>>> As with many things getting people to adopt it is the trick. >>>>>> >>>>>> John B. >>>>>> >>>>>> On Nov 9, 2013, at 8:15 AM, Torsten Lodderstedt >>>>>> > wrote: >>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>> why not make the more secure option the only one? >>>>>>> >>>>>>> regards, >>>>>>> Torsten. >>>>>>> >>>>>>> >>>>>>> >>>>>>> John Bradley > >>>>>>> schrieb: >>>>>>> >>>>>>> With a native app using a captive browser with no >>>>>>> malware, only the response is susceptible to >>>>>>> interception, making encrypting the request redundant. >>>>>>> In other environments and with some user groups the >>>>>>> request's challenge needs to be protected from >>>>>>> interception. This may be more the case in a desktop >>>>>>> environment where there is less control over the browser. >>>>>>> >>>>>>> I expect that we will come to two options one >>>>>>> unprotected requests and one for protected requests. >>>>>>> >>>>>>> To Phil's point this is not about identifying the class >>>>>>> of software this is about matching a response to an >>>>>>> instance of software. >>>>>>> A software statement gives you a hint about the class of >>>>>>> software but not the instance without per client >>>>>>> registration. >>>>>>> >>>>>>> This method gives you the ability to securely return the >>>>>>> token to only the instance of the client that requested >>>>>>> it without the overhead of per instance dynamic >>>>>>> registration. >>>>>>> >>>>>>> This is a practical solution to a real problem people >>>>>>> are having today, and versions of this are in production >>>>>>> now. >>>>>>> >>>>>>> Nat and I are trying to document it so that there can be >>>>>>> interoperability rather than every AS doing something >>>>>>> different. >>>>>>> >>>>>>> John B. >>>>>>> >>>>>>> On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>>> Hi Nat, >>>>>>>> >>>>>>>> what's the rationale for having different algorithms to >>>>>>>> produce a code challenges? As this may cause interop >>>>>>>> issues there should be good reasons to introduce variants. >>>>>>>> >>>>>>>> regards, >>>>>>>> Torsten. >>>>>>>> >>>>>>>> >>>>>>>> Am 19.10.2013 12:15, schrieb Nat Sakimura: >>>>>>>>> Incorporated the discussion at Berlin meeting and >>>>>>>>> after in the ML. >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> >>>>>>>>> Nat >>>>>>>>> >>>>>>>>> ---------- Forwarded message ---------- >>>>>>>>> From: >>>>>>>> > >>>>>>>>> Date: 2013/10/19 >>>>>>>>> Subject: New Version Notification for >>>>>>>>> draft-sakimura-oauth-tcse-02.txt >>>>>>>>> To: Nat Sakimura >>>>>>>> >, John Bradley >>>>>>>>> >>>>>>>> >, Naveen Agarwal >>>>>>>>> > >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> A new version of I-D, draft-sakimura-oauth-tcse-02.txt >>>>>>>>> has been successfully submitted by Nat Sakimura and >>>>>>>>> posted to the >>>>>>>>> IETF repository. >>>>>>>>> >>>>>>>>> Filename: draft-sakimura-oauth-tcse >>>>>>>>> Revision: 02 >>>>>>>>> Title: OAuth Symmetric Proof of Posession for Code >>>>>>>>> Extension >>>>>>>>> Creation date: 2013-10-19 >>>>>>>>> Group: Individual Submission >>>>>>>>> Number of pages: 8 >>>>>>>>> URL: >>>>>>>>> http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt >>>>>>>>> Status: >>>>>>>>> http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse >>>>>>>>> Htmlized: >>>>>>>>> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02 >>>>>>>>> Diff: >>>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-tcse-02 >>>>>>>>> >>>>>>>>> Abstract: >>>>>>>>> The OAuth 2.0 public client utilizing authorization >>>>>>>>> code grant is >>>>>>>>> susceptible to the code interception attack. This >>>>>>>>> specification >>>>>>>>> describe a mechanism that acts as a control against >>>>>>>>> this threat. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Please note that it may take a couple of minutes from >>>>>>>>> the time of submission >>>>>>>>> until the htmlized version and diff are available at >>>>>>>>> tools.ietf.org . >>>>>>>>> >>>>>>>>> The IETF Secretariat >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Nat Sakimura (=nat) >>>>>>>>> Chairman, OpenID Foundation >>>>>>>>> http://nat.sakimura.org/ >>>>>>>>> @_nat_en >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> > --------------050504010101090607000108 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Dynamic client registration + stateless is probably the broader solution that also covers use-cases if I had to pick just one.

That's my point. I have to decide what to implement in my service since we need a solution for our (partner) apps. And right now I'm tending more towards dynamic client registration + stateless. In my opinion, it's not only broader but easier to use from a client developer's perspective (that's what I care more about than server-side complexity).

regards,
Torsten.

John B.

On Nov 10, 2013, at 12:57 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

One can relate all instances of the same app using an initial access token. So doing per client instance registration does not preclude to manage grants per app.



John Bradley <ve7jtb@ve7jtb.com> schrieb:
Yes  tcse is a way to use the code flow without per instance registration, and better security than a plain public client.  
Not every instance needs to needs registered as long as the redirect_uri is constant. 

There is however a difference in how grants are treated then you have multiple instances with the same client_id.
If you want all copies of a app that the user has installed across devices to have the same grants then use one client_id and tcse.

If you want the grants to be separate so that one instance has RW and the other RO scopes for example then you need dynamic client registration or to re-confirm all scopes each time and not prompt only for new scopes for the client.   So there are legitimate reasons for doing both.

John B.



On Nov 9, 2013, at 12:32 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Sounds interesting. 

I wonder about why one might choose a public model with tcse vs stateless client reg?  

Eg. Tcse might be more important for transient clients. 

Phil

On Nov 9, 2013, at 12:27, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi,

thanks for the explanation. Seems there is the simpler option sufficient to solve the original problem but it's not secure enough to be a general solution. 

Regarding implementation: The simpler option requires the developer to create a value of reasonable randomness and the second additionally requires to calculate the SHA correctly. I'm afraid client developers will have trouble implementing it correctly. That's why the idea of OAuth always was to push complexity to the server implementation.

While thinking about your proposal, I remembered a potential alternative. We initially discussed usage of dynamically issued client id/secrets (dyn. client registration) in order to mitigate the threat. This has two advantages:
- it utilizes general OAuth functionality
- usage of client credentials is easy from a client developers perspective

This idea was originally rejected due to the potential implications on scalability. The assumption was, potentially billions of client instances could not be managed by the AS in a reasonable way. Based on the outcome of the latest discussions around dynamic registration, we now know how to implement registration in a stateless way using client secrets as self-contained tokens. So this should not be a scalability issue any longer.

Should we reconsider this alternative?

regards,
Torsten.

Am 09.11.2013 um 19:04 schrieb Nat Sakimura <sakimura@gmail.com>:

And adding to it, it is Google's application team that needs to be persuaded. As usual, persuading application people to use crypto is hard. We have to strike a point that is acceptable to them as well as being somewhat sensible security-wise. Having option to bump up the security is important as a future migration path as well, hence the current design. 

=nat via iPhone

Nov 10, 2013 1:42、John Bradley <ve7jtb@ve7jtb.com> のメッセージ:

Simplicity for clients that don't need the extra security.   I happen to agree with you but it is Google that needs the convincing, as they have deployed the non crypto version.
As with many things getting people to adopt it is the trick.

John B.

On Nov 9, 2013, at 8:15 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi John,

why not make the more secure option the only one?

regards,
Torsten.



John Bradley <ve7jtb@ve7jtb.com> schrieb:
With a native app using a captive browser with no malware, only the response is susceptible to interception, making encrypting the request redundant.
In other environments and with some user groups the request's challenge needs to be protected from interception.  This may be more the case in a desktop environment where there is less control over the browser.

I expect that we will come to two options one unprotected requests and one for protected requests.

To Phil's point this is not about identifying the class of software this is about matching a response to an instance of software.   
A software statement gives you a hint about the class of software but not the instance without per client registration.

This method gives you the ability to securely return the token to only the instance of the client that requested it without the overhead of per instance dynamic registration.

This is a practical solution to a real problem people are having today, and versions of this are in production now.   

Nat and I are trying to document it so that there can be interoperability rather than every AS doing something different.

John B.

On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Nat,

what's the rationale for having different algorithms to produce a code challenges? As this may cause interop issues there should be good reasons to introduce variants.

regards,
Torsten.


Am 19.10.2013 12:15, schrieb Nat Sakimura:
Incorporated the discussion at Berlin meeting and after in the ML. 

Best, 

Nat

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: 2013/10/19
Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-02.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:        draft-sakimura-oauth-tcse
Revision:        02
Title:           OAuth Symmetric Proof of Posession for Code Extension
Creation date:   2013-10-19
Group:           Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-tcse-02

Abstract:
   The OAuth 2.0 public client utilizing authorization code grant is
   susceptible to the code interception attack.  This specification
   describe a mechanism that acts as a control against this threat.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--------------050504010101090607000108-- From lainhart@us.ibm.com Mon Nov 11 06:33:46 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4468821E8200 for ; Mon, 11 Nov 2013 06:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.854 X-Spam-Level: X-Spam-Status: No, score=-9.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zm-9B4Ab0Dc6 for ; Mon, 11 Nov 2013 06:33:32 -0800 (PST) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by ietfa.amsl.com (Postfix) with ESMTP id C013221E80D2 for ; Mon, 11 Nov 2013 06:33:31 -0800 (PST) Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 11 Nov 2013 07:33:30 -0700 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 11 Nov 2013 07:33:27 -0700 Received: from b01cxnp23032.gho.pok.ibm.com (b01cxnp23032.gho.pok.ibm.com [9.57.198.27]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 480056E8044 for ; Mon, 11 Nov 2013 09:33:25 -0500 (EST) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by b01cxnp23032.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rABEXRDk2687438 for ; Mon, 11 Nov 2013 14:33:27 GMT Received: from d01av03.pok.ibm.com (localhost [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rABEXQqR017594 for ; Mon, 11 Nov 2013 09:33:26 -0500 Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av03.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id rABEXQQH017582 for ; Mon, 11 Nov 2013 09:33:26 -0500 To: "IETF oauth WG" MIME-Version: 1.0 X-KeepSent: 732B0315:42B4EDA0-85257C20:004FBBBE; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP4 SHF39 May 13, 2013 Message-ID: From: Todd W Lainhart Date: Mon, 11 Nov 2013 09:33:24 -0500 X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 11/11/2013 09:33:26, Serialize complete at 11/11/2013 09:33:26 Content-Type: multipart/alternative; boundary="=_alternative 004FF5BF85257C20_=" X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13111114-9332-0000-0000-0000021B464B Subject: [OAUTH-WG] Introspection spec still active? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 14:33:46 -0000 This is a multipart message in MIME format. --=_alternative 004FF5BF85257C20_= Content-Type: text/plain; charset="US-ASCII" http://tools.ietf.org/html/draft-richer-oauth-introspection-04 expired as of 11/02/13. I'm assuming that this spec still has some traction, and that the expiration is not an indicator of retraction? Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainhart@us.ibm.com --=_alternative 004FF5BF85257C20_= Content-Type: text/html; charset="US-ASCII" http://tools.ietf.org/html/draft-richer-oauth-introspection-04 expired as of 11/02/13.  I'm assuming that this spec still has some traction, and that the expiration is not an indicator of retraction?



Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.com

--=_alternative 004FF5BF85257C20_=-- From sakimura@gmail.com Mon Nov 11 06:47:46 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6905A21F9E44 for ; Mon, 11 Nov 2013 06:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiKynwouPS0q for ; Mon, 11 Nov 2013 06:47:38 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D3B0C21F9D8B for ; Mon, 11 Nov 2013 06:47:35 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id ep20so1043160lab.20 for ; Mon, 11 Nov 2013 06:47:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xFAYGYkR0OTilWfPI9Beu222wyiRR4V/JiPo7PPD1ZU=; b=lV5aXug4NsCFVKLl9p0O98Tu2JxVxSttYmi3mOMvnNFHi3RtlUiHfcq2uq4to1wZM6 +Wyu1aWhy74TJed+7INq4Qn+FUr9NEt0fJ8WU+mCu6ENtclPuw0qQXYfTyKK9GJiIGp0 YdyW/4A6tAm0lTk0519V7KVn8X3DO3+YpLuDTi2lTeEt/pivhhza/oi5Lo8YEuI+RA+H 09Glo7g2lbeITyX/n/vD9lRxKT08bdGMz6Jb8UOFMPxf2SNhhDs0iInIM6FGX5MsQwvZ TACWkrQ60lznqd10oc3wgiKntXW9hJx/0zI1g9bwmOGhJs8HHdPCmf+9w2bxUHmr2CcO d4Sw== MIME-Version: 1.0 X-Received: by 10.112.151.5 with SMTP id um5mr25210lbb.76.1384181253078; Mon, 11 Nov 2013 06:47:33 -0800 (PST) Received: by 10.112.139.65 with HTTP; Mon, 11 Nov 2013 06:47:33 -0800 (PST) In-Reply-To: References: Date: Mon, 11 Nov 2013 23:47:33 +0900 Message-ID: From: Nat Sakimura To: Todd W Lainhart Content-Type: multipart/alternative; boundary=047d7b3a80e4e503b204eae7cfe1 Cc: IETF oauth WG Subject: Re: [OAUTH-WG] Introspection spec still active? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 14:47:46 -0000 --047d7b3a80e4e503b204eae7cfe1 Content-Type: text/plain; charset=ISO-8859-1 By no means. If Justin let it go, I will pick it up :-) 2013/11/11 Todd W Lainhart > *http://tools.ietf.org/html/draft-richer-oauth-introspection-04* expired > as of 11/02/13. I'm assuming that this spec still has some traction, and > that the expiration is not an indicator of retraction? > > > > > > > * Todd Lainhart Rational software IBM Corporation 550 King Street, > Littleton, MA 01460-1250* > > > * 1-978-899-4705 2-276-4705 (T/L) lainhart@us.ibm.com > * > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --047d7b3a80e4e503b204eae7cfe1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
By no means. If Justin let it go, I will pick it up :-)


2013/11/11= Todd W Lainhart <lainhart@us.ibm.com>
http://tools.ietf.org/html/draft-richer-oauth-introspection-04= expired as of 11/02/13. =A0I'm assuming that this spec still has some traction, and that the expiration is not an indicator of retraction?



Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.co= m


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--047d7b3a80e4e503b204eae7cfe1-- From jricher@mitre.org Mon Nov 11 13:55:20 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BBD11E812A for ; Mon, 11 Nov 2013 13:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.386 X-Spam-Level: X-Spam-Status: No, score=-6.386 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LlYcCdaGc5E for ; Mon, 11 Nov 2013 13:55:15 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 53BFC11E8114 for ; Mon, 11 Nov 2013 13:55:15 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C3E901F0637; Mon, 11 Nov 2013 16:55:14 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A47581F04C3; Mon, 11 Nov 2013 16:55:14 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.251]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 16:55:14 -0500 From: "Richer, Justin P." To: Nat Sakimura , Todd W Lainhart Thread-Topic: [OAUTH-WG] Introspection spec still active? Thread-Index: AQHO3usLnWUdIwk8ZUK0DMCMQI6c6Zogb+OAgAAjWD8= Date: Mon, 11 Nov 2013 21:55:13 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E33BEB8CAIMCMBX01MITREOR_" MIME-Version: 1.0 Cc: IETF oauth WG Subject: Re: [OAUTH-WG] Introspection spec still active? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 21:55:20 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E33BEB8CAIMCMBX01MITREOR_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Expiration of drafts happens automatically after a set amount of time has p= assed without edits. There haven't needed to be any edits to the introspect= ion draft in many months (apart from a couple typos), so I haven't updated = it. -- Justin ________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of Nat Saki= mura [sakimura@gmail.com] Sent: Monday, November 11, 2013 9:47 AM To: Todd W Lainhart Cc: IETF oauth WG Subject: Re: [OAUTH-WG] Introspection spec still active? By no means. If Justin let it go, I will pick it up :-) 2013/11/11 Todd W Lainhart = > http://tools.ietf.org/html/draft-richer-oauth-introspection-04 expired as o= f 11/02/13. I'm assuming that this spec still has some traction, and that = the expiration is not an indicator of retraction? Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainhart@us.ibm.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --_000_B33BFB58CCC8BE4998958016839DE27E33BEB8CAIMCMBX01MITREOR_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Expiration of drafts happens automatically after a set amount of tim= e has passed without edits. There haven't needed to be any edits to the int= rospection draft in many months (apart from a couple typos), so I haven't updated it.

 -- Justin

From: oauth-bounces@ietf.org [oauth-bounc= es@ietf.org] on behalf of Nat Sakimura [sakimura@gmail.com]
Sent: Monday, November 11, 2013 9:47 AM
To: Todd W Lainhart
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] Introspection spec still active?

By no means. If Justin let it go, I will pick it up :-)


2013/11/11 Todd W Lainhart <= ;lainhart@us.ibm.c= om>
http://tools.ietf.org/= html/draft-richer-oauth-introspection-04 expired as of 11/02/13.  I'm assuming= that this spec still has some traction, and that the expiration is not an = indicator of retraction?



Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.co= m


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en
--_000_B33BFB58CCC8BE4998958016839DE27E33BEB8CAIMCMBX01MITREOR_-- From sakimura@gmail.com Mon Nov 11 13:57:13 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D496721E80F8 for ; Mon, 11 Nov 2013 13:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBzkrpUXrB3b for ; Mon, 11 Nov 2013 13:57:13 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 68CAB21E80FC for ; Mon, 11 Nov 2013 13:57:09 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id ec20so2015449lab.15 for ; Mon, 11 Nov 2013 13:57:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LF/+Zc1ZfkFfOsmUxJhENK3FUBVbTMyTeiUTQR01Urg=; b=LPyAWVUvY15vBY3sr5Jc1snSG9E4xABLUHzDxWuajGWbhJcTHppNc5nrdI6ChEfbS9 SQVufSPFk1eXTQSw5c9QkXjkJLgpEDYvKdO3iMmKvGPj0c0/u88o5y1KV1NFmy/rvcil SvOhUoajdXlsI6SSrPGvlvDViXFQZZ9SVgyZwDZRNRlo3L63vswInAd9aWgqcYuqMyzs g/6Q6jucgrDW6JbXpHtrTIz09VEhPrYS1CpXAR9IPN4C0hjab0nnfYXnvAXPD9d/YDjF c4dBMBNaYZQCZs7hYEqozSE4sqxTWYCrrNqNOdBW6+7gj2Nu4lKReBwjQ9tcgYjoIqf4 i76w== MIME-Version: 1.0 X-Received: by 10.112.144.197 with SMTP id so5mr23811846lbb.22.1384207028278; Mon, 11 Nov 2013 13:57:08 -0800 (PST) Received: by 10.112.139.65 with HTTP; Mon, 11 Nov 2013 13:57:08 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Nov 2013 06:57:08 +0900 Message-ID: From: Nat Sakimura To: "Richer, Justin P." Content-Type: multipart/alternative; boundary=047d7b3a82a8375aa304eaedd093 Cc: IETF oauth WG Subject: Re: [OAUTH-WG] Introspection spec still active? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 21:57:13 -0000 --047d7b3a82a8375aa304eaedd093 Content-Type: text/plain; charset=ISO-8859-1 Great. I may have something for you based on our implementation. I will get back to you individually. Best, Nat 2013/11/12 Richer, Justin P. > Expiration of drafts happens automatically after a set amount of time > has passed without edits. There haven't needed to be any edits to the > introspection draft in many months (apart from a couple typos), so I > haven't updated it. > > -- Justin > > ------------------------------ > *From:* oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of Nat > Sakimura [sakimura@gmail.com] > *Sent:* Monday, November 11, 2013 9:47 AM > *To:* Todd W Lainhart > *Cc:* IETF oauth WG > *Subject:* Re: [OAUTH-WG] Introspection spec still active? > > By no means. If Justin let it go, I will pick it up :-) > > > 2013/11/11 Todd W Lainhart > >> *http://tools.ietf.org/html/draft-richer-oauth-introspection-04* expired >> as of 11/02/13. I'm assuming that this spec still has some traction, and >> that the expiration is not an indicator of retraction? >> >> >> >> >> >> >> * Todd Lainhart Rational software IBM Corporation 550 King Street, >> Littleton, MA 01460-1250* >> >> >> * 1-978-899-4705 2-276-4705 (T/L) lainhart@us.ibm.com >> * >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --047d7b3a82a8375aa304eaedd093 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Great.=A0

I may have something for you = based on our implementation. I will get back to you individually.=A0
Best,=A0

Nat


2013/11/12 Richer, Justin P. <jricher= @mitre.org>
Expiration o= f drafts happens automatically after a set amount of time has passed withou= t edits. There haven't needed to be any edits to the introspection draf= t in many months (apart from a couple typos), so I haven't updated it.

=A0-- Justin

Fro= m: oauth-bo= unces@ietf.org [oauth-bounces@ietf.org] on behalf of Nat Sakimura [sakimura@gmail.com]
Sent: Monday, November 11, 2013 9:47 AM
To: Todd W Lainhart
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] Introspection spec still active?

By no means. If Justin let it go, I will pick it up :-)


2013/11/11 Todd W Lainhart <= ;lainhart@us.ibm.c= om>
http://tools.ietf.org/= html/draft-richer-oauth-introspection-04 expired as of 11/02/13. =A0I'm assumin= g that this spec still has some traction, and that the expiration is not an= indicator of retraction?



Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.co= m


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en



--
Nat Sakimura= (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--047d7b3a82a8375aa304eaedd093-- From internet-drafts@ietf.org Tue Nov 12 02:24:49 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8207F21E814D; Tue, 12 Nov 2013 02:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkdgDYKbaqVA; Tue, 12 Nov 2013 02:24:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D457A21E814F; Tue, 12 Nov 2013 02:24:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131112102444.28795.41999.idtracker@ietfa.amsl.com> Date: Tue, 12 Nov 2013 02:24:44 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 10:24:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : JSON Web Token (JWT) Author(s) : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-oauth-json-web-token-13.txt Pages : 29 Date : 2013-11-12 Abstract: JSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or MACed and/or encrypted. The suggested pronunciation of JWT is the same as the English word "jot". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-json-web-token-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Michael.Jones@microsoft.com Tue Nov 12 16:49:58 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C4D21E80AA; Tue, 12 Nov 2013 16:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvIuYI8n1knG; Tue, 12 Nov 2013 16:49:53 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id E0B0821F9FC7; Tue, 12 Nov 2013 16:49:52 -0800 (PST) Received: from BY2PR03CA032.namprd03.prod.outlook.com (10.242.234.153) by BY2PR03MB011.namprd03.prod.outlook.com (10.255.240.37) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 13 Nov 2013 00:49:51 +0000 Received: from BY2FFO11FD031.protection.gbl (2a01:111:f400:7c0c::158) by BY2PR03CA032.outlook.office365.com (2a01:111:e400:2c2c::25) with Microsoft SMTP Server (TLS) id 15.0.820.5 via Frontend Transport; Wed, 13 Nov 2013 00:49:51 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD031.mail.protection.outlook.com (10.1.14.196) with Microsoft SMTP Server (TLS) id 15.0.815.5 via Frontend Transport; Wed, 13 Nov 2013 00:49:50 +0000 Received: from TK5EX14MBXC287.redmond.corp.microsoft.com ([169.254.2.85]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0158.002; Wed, 13 Nov 2013 00:49:02 +0000 From: Mike Jones To: "jose@ietf.org" , "oauth@ietf.org" Thread-Topic: JOSE -18 and JWT -13 drafts continuing to address open issues Thread-Index: Ac7gCiTYd1n7q49zRduRHsk29V4y+Q== Date: Wed, 13 Nov 2013 00:49:01 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394377E79AC4@TK5EX14MBXC287.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.20] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394377E79AC4TK5EX14MBXC287r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(81542001)(71186001)(83072001)(76796001)(19300405004)(512954002)(66066001)(87936001)(74706001)(84326002)(44976005)(51856001)(6806004)(69226001)(65816001)(46102001)(81342001)(19580395003)(54356001)(80022001)(53806001)(83322001)(85306002)(81686001)(74366001)(76786001)(16236675002)(74876001)(81816001)(47446002)(74502001)(4396001)(74662001)(20776003)(63696002)(47736001)(49866001)(59766001)(77982001)(47976001)(50986001)(2656002)(76176001)(31966008)(80976001)(79102001)(15975445006)(15202345003)(87266001)(76482001)(77096001)(33656001)(56816003)(56776001)(54316002)(55846006)(6606295002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB011; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0029F17A3F X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Subject: [OAUTH-WG] JOSE -18 and JWT -13 drafts continuing to address open issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 00:49:58 -0000 --_000_4E1F6AAD24975D4BA5B168042967394377E79AC4TK5EX14MBXC287r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable JSON Object Signing and Encryption (JOSE) -18 and JSON Web Token (JWT) -13 = drafts have been published. The JOSE drafts contain changes to address 34 = of the 43 currently open issues. The JWT draft addresses several of the wo= rking group last call (WGLC) comments. No breaking changes were made to an= y of the specifications. The most visible change is that all registries no= w include Description fields - a change that was requested in JWT WGLC. See the Document History appendices for more details on the changes made an= d issues addressed. The drafts are available at: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-18 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-18 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-18 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-18 * http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-13 HTML formatted versions are also available at: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-18= .html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-1= 8.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-18.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-1= 8.html * http://self-issued.info/docs/draft-ietf-oauth-json-web-token-13.ht= ml -- Mike --_000_4E1F6AAD24975D4BA5B168042967394377E79AC4TK5EX14MBXC287r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

JSON Object Signing and Encryption (JOSE) -18 and JS= ON Web Token (JWT) -13 drafts have been published.  The JOSE drafts co= ntain changes to address 34 of the 43 currently open issues.  The JWT = draft addresses several of the working group last call (WGLC) comments.  No breaking changes were made to any of t= he specifications.  The most visible change is that all registries now= include Description fields – a change that was requested in JWT WGLC= .

 

See the Document History appendices for more details= on the changes made and issues addressed.

 

The drafts are available at:

·        http://tools.ietf.org/html/draft-ietf-jose= -json-web-signature-18

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-encryption-18

·        http://tools.ietf.org/html/draft-ietf-jose-json-= web-key-18

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-algorithms-18

·        http://tools.ietf.org/html/draft-ietf-oauth-j= son-web-token-13

 

HTML formatted versions are also available at:<= /o:p>

·        http://self-issued.info/docs/draft-= ietf-jose-json-web-signature-18.html

·        http://self-issued.info/docs/draft= -ietf-jose-json-web-encryption-18.html

·        http://self-issued.info/docs/draft-ietf-j= ose-json-web-key-18.html

·        http://self-issued.info/docs/draft= -ietf-jose-json-web-algorithms-18.html

·        http://self-issued.info/docs/draft-iet= f-oauth-json-web-token-13.html

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

--_000_4E1F6AAD24975D4BA5B168042967394377E79AC4TK5EX14MBXC287r_-- From wwwrun@rfc-editor.org Thu Nov 21 09:21:26 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EA41AE070 for ; Thu, 21 Nov 2013 09:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UW_EFeD5PDm5 for ; Thu, 21 Nov 2013 09:21:25 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id DECD01AE072 for ; Thu, 21 Nov 2013 09:21:24 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 11A2875E016; Thu, 21 Nov 2013 09:10:56 -0800 (PST) To: torsten@lodderstedt.net, sdronia@gmx.de, mscurtescu@google.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, Hannes.Tschofenig@gmx.net, derek@ihtfp.com From: RFC Errata System Message-Id: <20131121171056.11A2875E016@rfc-editor.org> Date: Thu, 21 Nov 2013 09:10:56 -0800 (PST) Cc: rfc-editor@rfc-editor.org, oauth@ietf.org, charles.marais@orange.com Subject: [OAUTH-WG] [Editorial Errata Reported] RFC7009 (3808) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 17:21:27 -0000 The following errata report has been submitted for RFC7009, "OAuth 2.0 Token Revocation". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7009&eid=3808 -------------------------------------- Type: Editorial Reported by: Charles MARAIS Section: 2.1 Original Text ------------- The link concerning the description of the client authentication (Section 2.3) is : http://tools.ietf.org/html/rfc7009#section-2.3 Corrected Text -------------- The link concerning the description of the client authentication (Section 2.3) should be : http://tools.ietf.org/html/rfc6749#section-2.3 Notes ----- In fact the pointed document is not the right one. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7009 (draft-ietf-oauth-revocation-11) -------------------------------------- Title : OAuth 2.0 Token Revocation Publication Date : August 2013 Author(s) : T. Lodderstedt, Ed., S. Dronia, M. Scurtescu Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From torsten@lodderstedt.net Thu Nov 21 10:23:17 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E64E1AE088 for ; Thu, 21 Nov 2013 10:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7tO4x9M3XO6 for ; Thu, 21 Nov 2013 10:23:15 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) by ietfa.amsl.com (Postfix) with ESMTP id A85021AE0B3 for ; Thu, 21 Nov 2013 10:23:14 -0800 (PST) Received: from [79.253.38.232] (helo=android-cd24e55ff4f45acd.fritz.box) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1VjYuA-0000Mj-7s; Thu, 21 Nov 2013 19:23:06 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <20131121171056.11A2875E016@rfc-editor.org> References: <20131121171056.11A2875E016@rfc-editor.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----VX103BR0Q88ZQL7Y645ZGP148GOKZI" From: Torsten Lodderstedt Date: Thu, 21 Nov 2013 19:22:55 +0100 To: RFC Errata System , sdronia@gmx.de, mscurtescu@google.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, Hannes.Tschofenig@gmx.net, derek@ihtfp.com Message-ID: X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: oauth@ietf.org, charles.marais@orange.com Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC7009 (3808) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 18:23:17 -0000 ------VX103BR0Q88ZQL7Y645ZGP148GOKZI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi all, Charles is right. This reference should be corrected. Regards, Torsten. RFC Errata System schrieb: >The following errata report has been submitted for RFC7009, >"OAuth 2.0 Token Revocation". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=7009&eid=3808 > >-------------------------------------- >Type: Editorial >Reported by: Charles MARAIS > >Section: 2.1 > >Original Text >------------- >The link concerning the description of the client authentication > >(Section 2.3) is : > >http://tools.ietf.org/html/rfc7009#section-2.3 > >Corrected Text >-------------- >The link concerning the description of the client authentication > >(Section 2.3) should be : > >http://tools.ietf.org/html/rfc6749#section-2.3 > >Notes >----- >In fact the pointed document is not the right one. > >Instructions: >------------- >This errata is currently posted as "Reported". If necessary, please >use "Reply All" to discuss whether it should be verified or >rejected. When a decision is reached, the verifying party (IESG) >can log in to change the status and edit the report, if necessary. > >-------------------------------------- >RFC7009 (draft-ietf-oauth-revocation-11) >-------------------------------------- >Title : OAuth 2.0 Token Revocation >Publication Date : August 2013 >Author(s) : T. Lodderstedt, Ed., S. Dronia, M. Scurtescu >Category : PROPOSED STANDARD >Source : Web Authorization Protocol >Area : Security >Stream : IETF >Verifying Party : IESG ------VX103BR0Q88ZQL7Y645ZGP148GOKZI Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi all,

Charles is right. This reference should be corrected.

Regards,
Torsten.



RFC Errata System <rfc-editor@rfc-editor.org> schrieb:
The following errata report has been submitted for RFC7009,
"OAuth 2.0 Token Revocation".


You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7009&eid=3808


Type: Editorial
Reported by: Charles MARAIS <charles.marais@orange.com>

Section: 2.1

Original Text
-------------
The link concerning the description of the client authentication

(Section 2.3) is :

http://tools.ietf.org/html/rfc7009#section-2.3

Corrected Text
--------------
The link concerning the description of the client authentication

(Section 2.3) should be :

http://tools.ietf.org/html/rfc6749#section-2.3

Notes
-----
In fact the pointed document is not the right one.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 


RFC7009 (draft-ietf-oauth-revocation-11)

Title               : OAuth 2.0 Token Revocation
Publication Date    : August 2013
Author(s)           : T. Lodderstedt, Ed., S. Dronia, M. Scurtescu
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG
------VX103BR0Q88ZQL7Y645ZGP148GOKZI-- From wwwrun@rfc-editor.org Mon Nov 25 14:07:39 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F2E1AE042 for ; Mon, 25 Nov 2013 14:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAnSiS34yzKj for ; Mon, 25 Nov 2013 14:07:38 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id EA7DA1AE03A for ; Mon, 25 Nov 2013 14:07:37 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 3C94375E001; Mon, 25 Nov 2013 14:07:34 -0800 (PST) To: charles.marais@orange.com From: rfc-editor@rfc-editor.org Message-Id: <20131125220734.3C94375E001@rfc-editor.org> Date: Mon, 25 Nov 2013 14:07:34 -0800 (PST) Cc: RFC Editor , Derek Atkins , oauth@ietf.org Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC7009 (3808) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 22:07:39 -0000 Greetings, The RFC errata system is used for the RFCs as available from rfc-editor.org (in this case, http://www.rfc-editor.org/rfc/rfc7009.txt), as noted on http://www.rfc-editor.org/errata.php. Your report regarding http://tools.ietf.org/html/rfc7009 has been sent to the webmaster for tools.ietf.org, the maintainer of that site's HTML versions, which are created by the script rfcmarkup. The erratum has been removed. Thank you. RFC Editor/ar On Nov 21, 2013, at 12:10 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC7009, > "OAuth 2.0 Token Revocation". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=7009&eid=3808 > > -------------------------------------- > Type: Editorial > Reported by: Charles MARAIS > > Section: 2.1 > > Original Text > ------------- > The link concerning the description of the client authentication > (Section 2.3) is : > http://tools.ietf.org/html/rfc7009#section-2.3 > > Corrected Text > -------------- > The link concerning the description of the client authentication > (Section 2.3) should be : > http://tools.ietf.org/html/rfc6749#section-2.3 > > Notes > ----- > In fact the pointed document is not the right one. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7009 (draft-ietf-oauth-revocation-11) > -------------------------------------- > Title : OAuth 2.0 Token Revocation > Publication Date : August 2013 > Author(s) : T. Lodderstedt, Ed., S. Dronia, M. Scurtescu > Category : PROPOSED STANDARD > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG From prabath@wso2.com Thu Nov 28 03:51:57 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5E31AE08D for ; Thu, 28 Nov 2013 03:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dxj-z5v5e2Z for ; Thu, 28 Nov 2013 03:51:55 -0800 (PST) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE161AD68D for ; Thu, 28 Nov 2013 03:51:55 -0800 (PST) Received: by mail-oa0-f52.google.com with SMTP id h16so8852165oag.25 for ; Thu, 28 Nov 2013 03:51:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wso2.com; s=google; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=HfrPOJtuZQLAP0XkE5qeKvnbWkACrheYV0uFf3OKQZU=; b=bcc6DSS/uFyLHUkXXRq+T5nwnJ+5NfZ3xNz3ompC0sl0nY9ResRzjN5obAUca08YqL BtkXsw85rHSEDIBlI72YTyXR/OH+PnuHtu/iap85vwGeH/yCOdBeQgXh4AYvIPnjb7nm 6rVTY7hqjxEGA7RjbIyLSJbqJV/NXgOr1dACw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=HfrPOJtuZQLAP0XkE5qeKvnbWkACrheYV0uFf3OKQZU=; b=idJ1x70Luk7ELq4kLshO8rdhT2esjJYzU/7CAUZ4Cw6E5+970v6e2PmbYrrOvyvame dpbLyhSHJNhs1d6z6NKHKrAqbTQumsXBjfw5LHS/MUL/oCqcuNQxrHvX0BuB6PkTK6NJ Xljf9D7+aLnDrVI1HggL3Ff0uaQtspZY1FZx4AOByNQvIgL2eXNiI1+sP/YJa7mujrv3 7xrTBtcpy4CMeUoP5n/KxwhG3jnxlYA7KuuAK47VCGmqDPGSYCzKYQdUn5HZWznRMs/i /sCUNT+4SE2oAVMoASTb1uwfFgza+UGsmvTM/Zg3LV+jPSGEzz1V2ETZzBbK2OKcOFlv itJg== X-Gm-Message-State: ALoCoQk3dUA4BoiOTgs44GusxeWbK4zPL6myHaFPJ9/JLYO2AlyOJvMiii3hbtW6xdgx9bRQ12FL MIME-Version: 1.0 X-Received: by 10.60.42.72 with SMTP id m8mr164054oel.64.1385639514133; Thu, 28 Nov 2013 03:51:54 -0800 (PST) Received: by 10.60.134.135 with HTTP; Thu, 28 Nov 2013 03:51:54 -0800 (PST) Date: Thu, 28 Nov 2013 17:21:54 +0530 Message-ID: From: Prabath Siriwardena To: Nat Sakimura Content-Type: multipart/alternative; boundary=089e01536b1406e7a504ec3b5775 Cc: IETF oauth WG Subject: [OAUTH-WG] Adding resource owner id to the introspection response {was :Introspection spec still active? } X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 11:51:57 -0000 --089e01536b1406e7a504ec3b5775 Content-Type: text/plain; charset=ISO-8859-1 Currently the introspection response has an optional parameter to pass the client_id to the caller. It would also be useful to pass an ID token back in the response - just like in OpenID Connect - to include end user details. WDYT ? Thanks & regards, -Prabath On Tue, Nov 12, 2013 at 3:27 AM, Nat Sakimura wrote: > Great. > > I may have something for you based on our implementation. I will get back > to you individually. > > Best, > > Nat > > > 2013/11/12 Richer, Justin P. > > Expiration of drafts happens automatically after a set amount of time >> has passed without edits. There haven't needed to be any edits to the >> introspection draft in many months (apart from a couple typos), so I >> haven't updated it. >> >> -- Justin >> >> ------------------------------ >> *From:* oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of Nat >> Sakimura [sakimura@gmail.com] >> *Sent:* Monday, November 11, 2013 9:47 AM >> *To:* Todd W Lainhart >> *Cc:* IETF oauth WG >> *Subject:* Re: [OAUTH-WG] Introspection spec still active? >> >> By no means. If Justin let it go, I will pick it up :-) >> >> >> 2013/11/11 Todd W Lainhart >> >>> *http://tools.ietf.org/html/draft-richer-oauth-introspection-04* expired >>> as of 11/02/13. I'm assuming that this spec still has some traction, and >>> that the expiration is not an indicator of retraction? >>> >>> >>> >>> >>> >>> >>> * Todd Lainhart Rational software IBM Corporation 550 King Street, >>> Littleton, MA 01460-1250* >>> >>> >>> * 1-978-899-4705 2-276-4705 (T/L) lainhart@us.ibm.com >>> * >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> >> -- >> Nat Sakimura (=nat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://blog.api-security.org --089e01536b1406e7a504ec3b5775 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Currently the=A0introspection response has an optional par= ameter to pass the client_id to the caller. It would also be useful to pass= an ID token back in the response - just like in OpenID Connect - to includ= e end user details.

WDYT ?

T= hanks & regards,
-Prabath

On Tue, Nov 12, 2013 at 3:27 AM, Nat Sakimura <sakim= ura@gmail.com> wrote:
Great.=A0

I may have s= omething for you based on our implementation. I will get back to you indivi= dually.=A0

Best,=A0

Nat


2013/11/12 Richer, Justin P. <jricher= @mitre.org>

Expiration o= f drafts happens automatically after a set amount of time has passed withou= t edits. There haven't needed to be any edits to the introspection draf= t in many months (apart from a couple typos), so I haven't updated it.

=A0-- Justin

Fro= m: oauth-bo= unces@ietf.org [oauth-bounces@ietf.org] on behalf of Nat Sakimura [sakimura@gmail.com]
Sent: Monday, November 11, 2013 9:47 AM
To: Todd W Lainhart
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] Introspection spec still active?

By no means. If Justin let it go, I will pick it up :-)


2013/11/11 Todd W Lainhart <= ;lainhart@us.ibm.c= om>
http://tools.ietf.org/= html/draft-richer-oauth-introspection-04 expired as of 11/02/13. =A0I'm assumin= g that this spec still has some traction, and that the expiration is not an= indicator of retraction?



Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.co= m


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundatio= n
http://nat.saki= mura.org/
@_nat_en

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




--
Thanks &= amp; Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://blog.api-security.org
--089e01536b1406e7a504ec3b5775-- From sheenalovespink@yahoo.com Fri Nov 29 04:30:31 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114C21AE016 for ; Fri, 29 Nov 2013 04:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO=1, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kA1CYdnAbXvW for ; Fri, 29 Nov 2013 04:30:29 -0800 (PST) Received: from nm10-vm0.bullet.mail.bf1.yahoo.com (nm10-vm0.bullet.mail.bf1.yahoo.com [98.139.213.147]) by ietfa.amsl.com (Postfix) with SMTP id E136E1ADF7E for ; Fri, 29 Nov 2013 04:30:28 -0800 (PST) Received: from [98.139.212.152] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 29 Nov 2013 12:30:27 -0000 Received: from [98.139.212.250] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 29 Nov 2013 12:30:27 -0000 Received: from [127.0.0.1] by omp1059.mail.bf1.yahoo.com with NNFMP; 29 Nov 2013 12:30:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 544401.92197.bm@omp1059.mail.bf1.yahoo.com Received: (qmail 90776 invoked by uid 60001); 29 Nov 2013 12:30:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1385728227; bh=NG+2TDUHTXVT+NYkXvbDEqd9YlZKpTqcsTqDktu8S1Q=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ljCbf8GCXTgnHxg0f2smqsKPPuEpw0p5HmK1wL7N6CwCtrI274jHl8I832KS8b8Z5os1mXMWfDqwqrO8GU0b/5lrpJNgzAPlREufJHc6y6JGxYP4F/3qsEcAN52hCXki7qFx6PqDTJ5YOdBtKxn+f3vmFIuDhaZIPHtXjcifT3c= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Ek3NFdx7d1UBs7pWCRfaSZZq4e3VE/dRAsQovVRCreEF69FcU5uLAG8HLIAbr+YT8QrrYboxTEKLmuCe8I6RwrbgUGsdzuakcP8/LBV31whWfQb5jOHSvyOpoyeigWSIzne12O5sWWLpTGyHzmk2LXTA4qgb1yjqEKyBihu5KGM=; X-YMail-OSG: 5GHJve4VM1myHjltk_yTOYl0IEWNm5IWG8lpUGIy9Wx4w3p EWt4D87cQhRE6Su6aSF0CPxyYPykKSl0zcetab.UF8wA5QI.0QfE9.ag509n C8n7TMwP9wTUiprFVKxnzAiUTeQT7Jimr43ggPbD._Jz6.iSrLAnRwpCckUo sva1Oa1dz3t58pk214LLkR4Xu3p1zz6yLrQbCOHFEs1P.zTcXdvIptplWtl5 oZ70btXTjjuL2BdIo4fTHT8x5y6r8_Tu43zrLA8jdESAa8UbujorRT5OgxdG 9Si1H4Nuk68LzI34ExY0niLv3ujeLA6aKuGun0m5cBF1DpHbKO5GwwQdhaSS caFKMkuMMZSr7EE3ucgfSW3D5I89onzOq4qj0Q5HmZhMg5gpea1ZscauwEUB s0sF4ctmOilTcQw5w1kR9Suins4.eXR.ij9Xbhh_GUJgzDVV4DSuTShvNrRu wfeUofUAbwPb9m5BUmSIJJHZ.QhvDXOJMY4rTHzE_TvOYF0TBB.nXTsaSWar faQqx0kB80rRMCmqLjpoaLflEMGXS5FMSqcH14giLd7BHxL_SMns2gHxLLk2 8VdNnu76mN9rgffyxEwkgsGPlbGbuH.TxoBtR6827OzFgo4mxvph6dCo_pGH hh_Q- Received: from [70.176.72.239] by web140001.mail.bf1.yahoo.com via HTTP; Fri, 29 Nov 2013 04:30:27 PST X-Rocket-MIMEInfo: 002.001, aW0gaW4gbmVlZCBvZiBpbmxpZ2h0bmVuCsKgCk1ycy4gU2hlZW5hIHByZXNsZXkgQ2FycmlsbG8KCgoKT24gVHVlc2RheSwgTm92ZW1iZXIgMjYsIDIwMTMgMTowMCBQTSwgIm9hdXRoLXJlcXVlc3RAaWV0Zi5vcmciIDxvYXV0aC1yZXF1ZXN0QGlldGYub3JnPiB3cm90ZToKIApTZW5kIE9BdXRoIG1haWxpbmcgbGlzdCBzdWJtaXNzaW9ucyB0bwrCoMKgwqAgb2F1dGhAaWV0Zi5vcmcKClRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNpdArCoMKgwqAgaHR0cHMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.167.602 References: Message-ID: <1385728227.69393.YahooMailNeo@web140001.mail.bf1.yahoo.com> Date: Fri, 29 Nov 2013 04:30:27 -0800 (PST) From: Sheena Carrillo To: "oauth@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1722594484-1325766651-1385728227=:69393" Subject: Re: [OAUTH-WG] OAuth Digest, Vol 61, Issue 46 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Sheena Carrillo List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 12:30:31 -0000 --1722594484-1325766651-1385728227=:69393 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable im in need of inlightnen=0A=A0=0AMrs. Sheena presley Carrillo=0A=0A=0A=0AOn= Tuesday, November 26, 2013 1:00 PM, "oauth-request@ietf.org" wrote:=0A =0ASend OAuth mailing list submissions to=0A=A0=A0=A0= oauth@ietf.org=0A=0ATo subscribe or unsubscribe via the World Wide Web, vi= sit=0A=A0=A0=A0 https://www.ietf.org/mailman/listinfo/oauth=0Aor, via email= , send a message with subject or body 'help' to=0A=A0=A0=A0 oauth-request@i= etf.org=0A=0AYou can reach the person managing the list at=0A=A0=A0=A0 oaut= h-owner@ietf.org=0A=0AWhen replying, please edit your Subject line so it is= more specific=0Athan "Re: Contents of OAuth digest..."=0A=0A=0AToday's Top= ics:=0A=0A=A0 1. Re: [Editorial Errata Reported] RFC7009 (3808)=0A=A0 =A0 = =A0 (rfc-editor@rfc-editor.org)=0A=0A=0A-----------------------------------= -----------------------------------=0A=0AMessage: 1=0ADate: Mon, 25 Nov 201= 3 14:07:34 -0800 (PST)=0AFrom: rfc-editor@rfc-editor.org =0ATo: charles.mar= ais@orange.com=0ACc: RFC Editor , Derek Atkins= =0A=A0=A0=A0 , oauth@ietf.org=0ASubject: Re: [OAUTH-WG] [E= ditorial Errata Reported] RFC7009 (3808)=0AMessage-ID: <20131125220734.3C94= 375E001@rfc-editor.org>=0A=0AGreetings,=0A=0AThe RFC errata system is used = for the RFCs as available from rfc-editor.org (in this case, http://www.rfc= -editor.org/rfc/rfc7009.txt), as noted on http://www.rfc-editor.org/errata.= php.=0A=0AYour report regarding http://tools.ietf.org/html/rfc7009 has been= sent to the webmaster for tools.ietf.org, the maintainer of that site's HT= ML versions, which are created by the script rfcmarkup.=0A=0AThe erratum ha= s been removed.=0A=0AThank you.=0ARFC Editor/ar=0A=0AOn Nov 21, 2013, at 12= :10 PM, RFC Errata System wrote:=0A=0A> The following errata report has bee= n submitted for RFC7009,=0A> "OAuth 2.0 Token Revocation".=0A> =0A> -------= -------------------------------=0A> You may review the report below and at:= =0A> http://www.rfc-editor.org/errata_search.php?rfc=3D7009&eid=3D3808=0A> = =0A> --------------------------------------=0A> Type: Editorial=0A> Reporte= d by: Charles MARAIS =0A> =0A> Section: 2.1=0A> = =0A> Original Text=0A> -------------=0A> The link concerning the descriptio= n of the client authentication=0A> (Section 2.3) is :=0A> http://tools.ietf= .org/html/rfc7009#section-2.3=0A> =0A> Corrected Text=0A> --------------=0A= > The link concerning the description of the client authentication=0A> (Sec= tion 2.3) should be :=0A> http://tools.ietf.org/html/rfc6749#section-2.3=0A= > =0A> Notes=0A> -----=0A> In fact the pointed document is not the right on= e.=0A> =0A> Instructions:=0A> -------------=0A> This errata is currently po= sted as "Reported". If necessary, please=0A> use "Reply All" to discuss whe= ther it should be verified or=0A> rejected. When a decision is reached, the= verifying party (IESG)=0A> can log in to change the status and edit the re= port, if necessary. =0A> =0A> --------------------------------------=0A> RF= C7009 (draft-ietf-oauth-revocation-11)=0A> --------------------------------= ------=0A> Title=A0 =A0 =A0 =A0 =A0 =A0 =A0 : OAuth 2.0 Token Revocation= =0A> Publication Date=A0 =A0 : August 2013=0A> Author(s)=A0 =A0 =A0 =A0 =A0= : T. Lodderstedt, Ed., S. Dronia, M. Scurtescu=0A> Category=A0 =A0 =A0 = =A0 =A0 =A0 : PROPOSED STANDARD=0A> Source=A0 =A0 =A0 =A0 =A0 =A0 =A0 : Web= Authorization Protocol=0A> Area=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Security= =0A> Stream=A0 =A0 =A0 =A0 =A0 =A0 =A0 : IETF=0A> Verifying Party=A0 =A0 := IESG=0A=0A=0A------------------------------=0A=0ASubject: Digest Footer=0A= =0A_______________________________________________=0AOAuth mailing list=0AO= Auth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A=0A=0A-------= -----------------------=0A=0AEnd of OAuth Digest, Vol 61, Issue 46=0A******= ******************************* --1722594484-1325766651-1385728227=:69393 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
im in need of inlightnen
 
Mrs. Sheena presley Carrillo


On Tuesday, November 26, 201= 3 1:00 PM, "oauth-request@ietf.org" <oauth-request@ietf.org> wrote:
Send OAuth mailing list s= ubmissions to
    oauth@ietf.org

To subscribe or unsu= bscribe via the World Wide Web, visit
    https://www.ietf.org/mailman/li= stinfo/oauth
or, via email, send a message with subject or body 'hel= p' to
    oauth-request@ietf.org

You = can reach the person managing the list at
    oauth= -owner@ietf.org

When replying, please edit your Subject line so = it is more specific
than "Re: Contents of OAuth digest..."


To= day's Topics:

  1. Re: [Editorial Errata Reported] RFC7009 (38= 08)
      (rfc-editor@rfc-editor.org)

-----------------------------------------------------------------= -----

Message: 1
Date: Mon, 25 Nov 2013 14:07:34 -0800 (PST)
F= rom: rfc-editor@rfc-editor.org
To: ch= arles.marais@orange.com
Cc: RFC Editor <rfc-editor= @rfc-editor.org>, Derek Atkins
    <derek@ihtfp.com= >, oauth@ietf.org
Subject: Re: [OAUTH-WG] [Editorial Errata Reported= ] RFC7009 (3808)
Message-ID: <20131125220734.3C94375E001@rfc= -editor.org>

Greetings,

The RFC errata system is used = for the RFCs as available from rfc-editor.org (in this case, http://www.rfc-ed= itor.org/rfc/rfc7009.txt), as noted on http://www.rfc-editor.org/errata= .php.

Your report regarding http://tools.ietf.org/html/rfc7009 has been se= nt to the webmaster for tools.ietf.org, the maintainer of that site's HTML = versions, which are created by the script rfcmarkup.

The erratum has= been removed.

Thank you.
RFC Editor/ar

On Nov 21, 2013, a= t 12:10 PM, RFC Errata System wrote:

> The following errata repor= t has been submitted for RFC7009,
> "OAuth 2.0 Token Revocation".
= >
> --------------------------------------
> You may review the= report below and at:
> http://www.rfc-edito= r.org/errata_search.php?rfc=3D7009&eid=3D3808
>
> ----= ----------------------------------
> Type: Editorial
> Reported= by: Charles MARAIS <charles.marais@orange.com>>
> Section: 2.1
>
> Original Text
> --------= -----
> The link concerning the description of the client authenticat= ion
> (Section 2.3) is :
> http://tools.ietf.org/html/rfc7009= #section-2.3
>
> Corrected Text
> --------------
= > The link concerning the description of the client authentication
&g= t; (Section 2.3) should be :
> http://tools.ietf.org/html/rfc6749#section-2.3<= /a>
>
> Notes
> -----
> In fact the pointed docume= nt is not the right one.
>
> Instructions:
> -----------= --
> This errata is currently posted as "Reported". If necessary, ple= ase
> use "Reply All" to discuss whether it should be verified or
= > rejected. When a decision is reached, the verifying party (IESG)
&g= t; can log in to change the status and edit the report, if necessary.
&= gt;
> --------------------------------------
> RFC7009 (draft-= ietf-oauth-revocation-11)
> --------------------------------------> Title              : OAuth 2.0 To= ken Revocation
> Publication Date    : August 2013
> = Author(s)          : T. Lodderstedt, Ed., S. Dronia, M. Scurtescu
> Category          &n= bsp; : PROPOSED STANDARD
> Source          &= nbsp;   : Web Authorization Protocol
> Area      =           : Security
> Stream    &= nbsp;         : IETF
> Verifying Party  &nbs= p; : IESG


------------------------------

Subject: Digest= Footer

_______________________________________________
OAuth mai= ling list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= br>

------------------------------

End of OAuth Digest, Vol 6= 1, Issue 46
*************************************


--1722594484-1325766651-1385728227=:69393--