Dear Michael Jones, John Bradley, Nat Sakimura:
An IPR disclosure that pertains to your Internet-Draft entitled "JSON Web Token
(JWT)" (draft-ietf-oauth-json-web-token) was submitted to the IETF Secretariat
on 2013-02-19 and has been posted on the "IETF Page of Intellectual Property
Rights Discl
Sorry I did not intend to imply that what Barry is asking for is contradictory
to MTI, only that it is different enough that it may require more than MTI of
the existing features.
As stated in the second line of the message.
I think we need to get down to discussing specific changes.
John B.
O
All of this discussion is occurring at a pretty abstract level. I hope we can
soon make it concrete, because then it would be actionable.
Do any of you who felt that changes might be needed to the Assertions spec or
related specs have specific textual changes to propose to any of the specs,
wh
> I can tell you that I don't think Barry and I are asking for
> contradictory things. They are different, but not contradictory,
> and have the same goal (interop). I believe Barry would agree
> with that.
>
> Saying that field X is MTI can be entirely consistent with
> defining a protocol that al
At the moment no,
The HoK work is ongoing.
If you are talking about using an assertion as a authorization grant the
subject should be the resource owner or some proxy for that.
In Connect that would be the user_id not the client_id. We have added
Authorized party "azp" to connect id_tokens
On 02/19/2013 02:58 PM, John Bradley wrote:
> Yes but that contradicts what Barry is appearing to ask for which is run time
> interoperability, by profile or configuration.
I can tell you that I don't think Barry and I are asking for
contradictory things. They are different, but not contradicto
Yes but that contradicts what Barry is appearing to ask for which is run time
interoperability, by profile or configuration.
While having code available in libraries is generally a good thing, I agree.
That is likely not going to address all of Barry's issues.
A number of us recommended that A
The scope of assertion based client authentication is only in OAuth and
only for the client calling the AS's token endpoint. Defining a general
HTTP auth scheme for assertions would have a much broader scope and be much
more difficult to standardize.
On Tue, Feb 19, 2013 at 6:54 AM, Sergey Beryoz
Yeah, in general the client identification/authentication is independent
from the grant being presented. There may be policy (maybe unidentified
clients aren't allowed) or other protocol details (like some kind of HoK
bound to the client, though that doesn't exist yet) that dictate more
requirement
Hi,
Assertions like SAML2 Bearer can be used for authenticating the client.
Why a dedicated Authorization scheme can not be introduced, instead of
or in addition to "client_assertion" & "client_assertion_type" parameters ?
IMHO, the following
Authorization: SAML "base64url-encoded assertion"
10 matches
Mail list logo
