FYI, I have been writing HoK for JWT/JWS Token by introducing a new claim 'cid'.
=nat via iPhone
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@xxxxxxxxxxxxxx>
д� 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.sujing@xxxxxxxxxx" <zhou.sujing@xxxxxxxxxx
> > wrote:
>
> Oh, But the description of assertion generation in the document
> should not be limited by bear assertion, right?
>
>
> Chuck Mortimore <cmortimore@xxxxxxxxxxxxxx> д� 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.sujing@xxxxxxxxxx"
<zhou.
> sujing@xxxxxxxxxx
> > > 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@xxxxxxxxxxxxxx> д� 2012-12-14
10:08:34:
> >
> > > On Dec 13, 2012, at 4:30 PM, "zhou.sujing@xxxxxxxxxx"
<zhou.
> > sujing@xxxxxxxxxx
> > > > 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@xxxxxxxxxxxxxx> д�
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.sujing@xxxxxxxxxx>
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@xxxxxxxx д� 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@xxxxxxxx mailing lists by 2012-12-24. Exceptionally,
> > comments may be
> > > > > sent to iesg@xxxxxxxx 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@xxxxxxxx
> > > > > https://www.ietf.org/mailman/listinfo/oauth
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > OAuth@xxxxxxxx
> > > > https://www.ietf.org/mailman/listinfo/oauth
|