I read through v10 from the perspective of an implementor, and it seemed
to me that properties of generated authorization code and its treatment
by various entities need to be called out explicitly as a
counter-measure against various simple attacks.
I would also comment that the exchanges bet
Okay, I'm fine with proceeding down this path. My takeaway is that I don't care
really where signatures live, but we definitely need a threat analysis and
security considerations document dealing with how and in what contexts to use
bearer tokens.
On Sep 28, 2010, at 10:08 AM, Eran Hammer-Lahav
(This is a draft overview of our next steps. Clearly, this can change based on
working group consensus.)
Proposal discussion
The working group is still discussing the compromise proposal for moving
section 5 out of the specification. So far there is general support but some
have raised concern
+1
I think this is a reasonable & practical proposal.
/thomas/
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Tuesday, September 28, 2010 2:26 AM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] Looking for a compromise on signatures and othe
Thanks Mark.
> -Original Message-
> From: Mark Mcgloin [mailto:mark.mcgl...@ie.ibm.com]
> Sent: Wednesday, September 29, 2010 8:28 AM
> I think acquiring and using a token can be considered core as you always
> need both. I don't have valid security consideration linkage between
> acquiri
> So this one I do feel more strongly about: We should only include crypto
> mechanisms that everybody MUST support. Otherwise, we'll have to invent some
> sort of negotiation step in the protocol: "do you support alg XYZ? No I
> don't, > please use ABC". Let's not do that.
>As just one datapoi
Eran Hammer-Lahav wrote on 29/09/2010 15:50:33:
> >
> > -1 to splitting acquiring and using a token. It may not confuse
> people actively
> > engaged in the WG but what about everyone else?
>
> We are already splitting it, by putting signatures elsewhere. Just
> because you might think bearer to
I agree bearer tokens are already in wide usage, I think it makes sense to have
a default interoperable token type, much like a token format and signature. The
security considerations section can point/cover any issues.
I'm not seeing what the splitting of the document is achieving except side
> -Original Message-
> From: Mark Mcgloin [mailto:mark.mcgl...@ie.ibm.com]
> Sent: Wednesday, September 29, 2010 12:55 AM
> I echo Dick's sentiment, mildly
>
> -1 to splitting acquiring and using a token. It may not confuse people
> actively
> engaged in the WG but what about everyone
I echo Dick's sentiment, mildly
-1 to splitting acquiring and using a token. It may not confuse people
actively engaged in the WG but what about everyone else?
Also, as Torsten and I look at security considerations, I wonder if there
are some examples that link the threat model for acquiring a to
10 matches
Mail list logo
