|
Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-assertions-08.txt> (Assertion Framework for OAuth 2.0) to Proposed Standard
2012-12-14 11:31:18
FYI, I have been writing HoK for JWT/JWS Token by introducing a new claim
'cid'.
=nat via iPhone
Dec 14, 2012 11:56、"zhou(_dot_)sujing(_at_)zte(_dot_)com(_dot_)cn"
<zhou(_dot_)sujing(_at_)zte(_dot_)com(_dot_)cn> のメッセ?`ジ:
Yep, could do it soon later.
Currently, I suggest a modification for
"The token service is the assertion issuer; its role is to fulfill
requests from clients, which present various
credentials, and mint assertions as requested, fill them with appropriate
information, and sign them." (in section 3 )
into
"The token service is the assertion issuer, *it could be implemented in
any entity besides client, e.g., Resource Owner, Authorization Server;* its
role is to fulfill requests from clients, which present various
credentials, and mint assertions as requested, fill them with appropriate
information, and sign them."
Chuck Mortimore <cmortimore(_at_)salesforce(_dot_)com> 写于 2012-12-14 10:44:05:
Correct. That said no one has yet profiled it for holder of key
- cmort
On Dec 13, 2012, at 6:39 PM, "zhou(_dot_)sujing(_at_)zte(_dot_)com(_dot_)cn" <
zhou(_dot_)sujing(_at_)zte(_dot_)com(_dot_)cn
wrote:
Oh, But the description of assertion generation in the document
should not be limited by bear assertion, right?
Chuck Mortimore <cmortimore(_at_)salesforce(_dot_)com> 写于 2012-12-14 10:34:13:
You want a holder of key pattern. The draft touches on it
The protocol parameters and processing rules defined in this document
are intended to support a client presenting a bearer assertion to an
authorization server. The use of holder-of-key assertions are not
precluded by this document, but additional protocol details would
need to be specified.
So - if you want this, you should put forth a holder of key
profiling of this draft and see if there are any issues. The only
profiles we have thus far are saml and jwt bearer assertions.
- cmort
On Dec 13, 2012, at 6:27 PM,
"zhou(_dot_)sujing(_at_)zte(_dot_)com(_dot_)cn" <zhou.
sujing(_at_)zte(_dot_)com(_dot_)cn
wrote:
I am not sure if the following usecase http://www.ietf.org/mail-
archive/web/oauth/current/msg10233.html
could be supported by assertion framework，
We have some discussion in
http://www.ietf.org/mail-archive/web/oauth/current/msg10203.html
http://www.ietf.org/mail-archive/web/oauth/current/msg10198.html
In my use case or in some other cases, assertions don't need
confidential protection,
basically STS don't have to authenticate a client before issueing
"assertion", if it could be called assertion here.
Example,I trust my laywer, I may issue an "assertion" stating
delegation in advance, and send to the lawyer when it is needed,
it could be I give the assertion to a false lawyer, but it does not
matter, because the lawyer has to prove he knows some credential
corresponding to his ID,
who is delegated some rights.
If assertion framework want to support this use case, then
generation of assertion should be relaxed,
otherwise new work is required to support the use case.
Chuck Mortimore <cmortimore(_at_)salesforce(_dot_)com> 写于 2012-12-14
10:08:34:
On Dec 13, 2012, at 4:30 PM,
"zhou(_dot_)sujing(_at_)zte(_dot_)com(_dot_)cn" <zhou.
sujing(_at_)zte(_dot_)com(_dot_)cn
wrote:
From the language, I got an impression that assertion is only
generated by token service after clients presenting some credentials,
there are may be some cases that "assertion" don't need client's
credential.
e.g., Resource owner as a token service could generate "assertion"
to a client he trusts, bu signing a statement that "This delegation
is given to a client called clinet-id
for doing something for me".
So how does the STS trust the client? Presumably if it is trusted
it has some level of authentication, yes?
-cmort
Chuck Mortimore <cmortimore(_at_)salesforce(_dot_)com> 写于 2012-12-14
00:39:03:
The language is simply meant to help illustrate how the framework
might be used. How do you think it will restrict usage? How
could it be improved?
-cmort
On Dec 12, 2012, at 11:04 PM,
<zhou(_dot_)sujing(_at_)zte(_dot_)com(_dot_)cn> wrote:
In "section 3
The token service is the assertion issuer; its
role is to fulfill requests from clients, which present various
credentials, and mint assertions as requested, fill them with
appropriate information, and sign them."
As I understand, an assertion generated by a STS, is done flollowing
thess steps:
1. Client presents credential and requests an assertion
2. STS generates assertion and sends to Client
Correct?
That may restrict the use cases that this assertion framework
could support,
is it a must?
oauth-bounces(_at_)ietf(_dot_)org 写于 2012-12-11 02:33:57:
The IESG has received a request from the Web Authorization
Protocol WG
(oauth) to consider the following document:
- 'Assertion Framework for OAuth 2.0'
<draft-ietf-oauth-assertions-08.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and
solicits
final comments on this action. Please send substantive comments
to the
ietf(_at_)ietf(_dot_)org mailing lists by 2012-12-24. Exceptionally,
comments may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please
retain the
beginning of the Subject line to allow automated sorting.
Abstract
This specification provides a framework for the use of
assertions
with OAuth 2.0 in the form of a new client
authenticationmechanism
and a new authorization grant type. Mechanisms are specified
for
transporting assertions during interactions with a token
endpoint, as
well as general processing rules.
The intent of this specification is to provide a common
framework for
OAuth 2.0 to interwork with other identity systems using
assertions,
and to provide alternative client authentication mechanisms.
Note that this specification only defines abstract
message flows and
processing rules. In order to be implementable, companion
specifications are necessary to provide the corresponding
concrete
instantiations.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ballot/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
OAuth mailing list
OAuth(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/oauth
|
|