https://datatracker.ietf.org/doc/draft-tschofenig-oauth-hotk/
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
I see. It was buried under "reg".
Phil
@independentid
www.independentid.com
phil.h...@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.
>
> What we are proposing is using an assertion
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 b
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
The redirect URI is built into the structure of the client_id that the client
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
-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
address Prateek's comment 2 (Why do we need both a "typ" claim and a "typ"
header name?) and James' comment 7 (The doc redefines the "cty" header
p
Identification is fine as long as it remains opaque and not specific to any
format. Authentication remains out of scope
From: John Bradley [mailto:ve7...@ve7jtb.com]
Sent: Monday, November 4, 2013 2:05 PM
To: Anthony Nadalin
Cc: Nat Sakimura; Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAU
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 N
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
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:sakim...@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-bra
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 yo
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:*
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 wo
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 t
We need to avoid encoding secrets and authentication with client_id as
authentication is not part of our mission
From: oauth-boun...@ietf.org [mailto:oauth-boun...@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:
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
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 a
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
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 mess
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 au
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."
>
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 ass
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 t
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 reference
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
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
>
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.
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 Comp
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-bea
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
30 matches
Mail list logo
