Elaborate Please...I've Yet To Ackowledge The Presentation Of How This Responce Came About, Or The Reckolection If Your Asking, Telling, Or, Saying... What Kind Of Communication & To What Comprehensive Level From Who It May Consern As To What You And I Of A Conclusion Of The Outcome Of This Reading Shall Come About
----- Original Message ----- From: [email protected] To: [email protected] Sent: Wed, 25 Dec 2013 15:00:07 -0500 (EST) Subject: OAuth Digest, Vol 62, Issue 14 Send OAuth mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/oauth or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. JWT Profile: Does it make sense to demand a subject? (Manfred Steyer) ---------------------------------------------------------------------- Message: 1 Date: Tue, 24 Dec 2013 22:38:42 +0100 From: "Manfred Steyer" <[email protected]> To: <[email protected]> Subject: [OAUTH-WG] JWT Profile: Does it make sense to demand a subject? Message-ID: <[email protected]> Content-Type: text/plain; charset="us-ascii" Hi, the draft about the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [1] says: "The JWT MUST contain a "sub" (subject) claim identifying theprincipal 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." I'm not sure, if this makes sense, cause in an federation-scenario the original jwt is issued in an other security-domain and the auth-server in question does not necessarily know the users in thouse domain. Furthermore, it is very likely that the auth-server is not interested in the subject claim, but just in other incoming claims in view of mapping them to outgoing ones. IMHO, all the auth-server can do with the subject-claim is to create a protocol entry that says that some action was performed for this subject. Do I see that right? Wishes, Manfred [1] https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20131224/59551074/attachment.html> ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest, Vol 62, Issue 14 ************************************* ----- Original Message ----- From: [email protected] To: [email protected] Sent: Tue, 24 Dec 2013 15:00:06 -0500 (EST) Subject: OAuth Digest, Vol 62, Issue 13 Send OAuth mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/oauth or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. JWT Attribute Certificates (Luke Howard) ---------------------------------------------------------------------- Message: 1 Date: Tue, 24 Dec 2013 12:03:41 +1100 From: Luke Howard <[email protected]> To: [email protected], [email protected] Subject: [OAUTH-WG] JWT Attribute Certificates Message-ID: <[email protected]> Content-Type: text/plain; charset="us-ascii" Seasons greetings! I've recently been working on adding support for selective claim disclosure to Mozilla Persona. A component of this was defining a JWT Attribute Certificate structure that can contain a set of claims bound to a primary JWT. The following Internet Draft documents this: Name: draft-howard-jwt-attr-cert Revision: 00 Title: JWT Attribute Certificate (JAC) Document date: 2013-12-24 Group: Individual Submission Pages: 18 URL: http://www.ietf.org/internet-drafts/draft-howard-jwt-attr-cert-00.txt Status: https://datatracker.ietf.org/doc/draft-howard-jwt-attr-cert/ Htmlized: http://tools.ietf.org/html/draft-howard-jwt-attr-cert-00 Abstract: A JSON Web Token Attribute Certificate (JAC) contains additional claims, grouped by scope, to be presented alongside a primary JWT. -- Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20131224/fd03ce1f/attachment.html> ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest, Vol 62, Issue 13 ************************************* ----- Original Message ----- From: [email protected] To: [email protected] Sent: Sun, 22 Dec 2013 15:00:05 -0500 (EST) Subject: OAuth Digest, Vol 62, Issue 12 Send OAuth mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/oauth or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. AUTO: Codur Sreedhar Pranam is out of the office (returning 01/08/2014) (Codur Sreedhar Pranam) ---------------------------------------------------------------------- Message: 1 Date: Sun, 22 Dec 2013 04:00:59 +0800 From: Codur Sreedhar Pranam <[email protected]> To: [email protected] Subject: [OAUTH-WG] AUTO: Codur Sreedhar Pranam is out of the office (returning 01/08/2014) Message-ID: <ofc83ab928.d0565fa7-on48257c48.006df45a-48257c48.006df...@sg.ibm.com> Content-Type: text/plain; charset="us-ascii" I am out of the office until 01/08/2014. Note: This is an automated response to your message "OAuth Digest, Vol 62, Issue 11" sent on 12/22/2013 4:00:06. This is the only notification you will receive while this person is away. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20131222/559b026d/attachment.html> ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest, Vol 62, Issue 12 ************************************* ----- Original Message ----- From: [email protected] To: [email protected] Sent: Sat, 21 Dec 2013 15:00:06 -0500 (EST) Subject: OAuth Digest, Vol 62, Issue 11 Send OAuth mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/oauth or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. Re: Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt (Sergey Beryozkin) ---------------------------------------------------------------------- Message: 1 Date: Fri, 20 Dec 2013 21:55:28 +0000 From: Sergey Beryozkin <[email protected]> To: [email protected] Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi IMHO the fact the transformation of the code_verifier is pluggable is a major improvement, and the whole text somehow reads much easier (few minor typos in the introduction). The only doubt is about the 'MUST' bit where the client is expected to figure out that the server supports this spec. Not a problem for me as I don't work on implementing a client, but it seems like it makes the whole process suddenly much more complex than may be it should be. Would it make sense to change 'MUST' to 'RECOMMENDED' and have the authorization service return a code_verifier_accepted or some similar response parameter, alongside with the 'code', instead ? Not really though, Cheers, Sergey On 19/10/13 11:15, Nat Sakimura wrote: > Incorporated the discussion at Berlin meeting and after in the ML. > > Best, > > Nat > > ---------- Forwarded message ---------- > From: ** <[email protected] <mailto:[email protected]>> > Date: 2013/10/19 > Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt > To: Nat Sakimura <[email protected] <mailto:[email protected]>>, John > Bradley <[email protected] <mailto:[email protected]>>, > Naveen Agarwal <[email protected] <mailto:[email protected]>> > > > > 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 > <http://tools.ietf.org>. > > The IETF Secretariat > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest, Vol 62, Issue 11 ************************************* _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
