One thing that concerns me is that scope is very different from a claim. An
claim is an assertion provided that may have some level of dispute/quality etc.
A scope defines what is request or what has been authorized. It's an absolute
thing. Therefore it is not a claim. Audience...maybe.
This
FYI: in case you are interested in that conversation. The topic about the value
of TLS and the problems with the PKI have surfaced in the past on this list.
Begin forwarded message:
From: Hannes Tschofenig hannes.tschofe...@gmx.net
Date: March 5, 2013 9:19:51 AM EST
To: 86attend...@ietf.org
I would not even want to confuse audience with scope. Maybe in the simplest of
cases, where there is a one-to-one mapping between scope and audience, but in
reality the RS could expose multiple APIs at the same endpoint. Granted the RS
could extract the audience field based on a fully
No. I am not confusing scope with audience.
There is no standard scope. So, the scope has to be either defined by the
resource or the authorization server.
Just stating scope is too vague that you will not able to find out whose
scope it is.
That is why I wrote that the scope has to be
+1. I think that is correct characterization.
Phil
Sent from my phone.
On 2013-03-11, at 12:42, Nat Sakimura sakim...@gmail.com wrote:
No. I am not confusing scope with audience.
There is no standard scope. So, the scope has to be either defined by the
resource or the authorization
Just a (perennial) reminder from me that scopes are proprietary strings in core
OAuth, but the UMA folks have proposed a way to standardize them because we
needed to:
http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-00
(pretty-printed, slightly updated version here:
It was brought up at the in-person meeting today that we'll want to consider
issues around internationalization and localization of human-readable fields
like client_name in the client registration. Which is to say: if a client
supports ten languages and wants to present itself in ten
FWIW, the closely related OpenID Connect client registration draft does
have some support for doing this, which could maybe be borrowed. See
client_name in §2 at
http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadataand
the examples.
client_name: My Example,
+1
2013/3/12 Brian Campbell bcampb...@pingidentity.com
FWIW, the closely related OpenID Connect client registration draft does
have some support for doing this, which could maybe be borrowed. See
client_name in §2 at
That is what I was thinking. It would be up to the AS to determine what
language and script to present based on the user preference.
While a large number of clients will be native and might be able to customize
themselves for a single user during registration , we don't want to forget the
My concern with this is that OIDC can get away with defining this
multi-language structure because it defines the mechanism once (in Messages)
and applies it to all user-readable strings throughout the whole application
protocol, of which there are several. Do we really want to pull in that
A fair question but what would need to be pulled in is really probably only
a couple sentences (and reference) from
http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts(note
the reference to 2.1.1.1.3 inside
The OAuth Feature Matrix spreadsheet that I talked about at the OAuth WG
meeting today is attached and available at
http://self-issued.info/misc/OAuth%20Feature%20Matrix.xlsx. Tony Nadalin and I
created it as a tool to characterize OAuth implementations to help promote
interoperability by
It does presume a definition of claim, which I suppose we could turn to
metadata field for DynReg and its extensions to be appropriately limiting.
But we also need a good definition of what a language-tag-less field means, and
whether or not it's required if the other fields are present or not
Similar work is in progress at Webfinger.
See: http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html
Paul is proposing the same syntax as Connect.
2013/3/12 Richer, Justin P. jric...@mitre.org
It does presume a definition of claim, which I suppose we could turn to
metadata
Please respond to this Doodle Poll http://doodle.com/fvrkmr8qtiktc3um to
indicate which times you'd prefer to meet tomorrow (Tuesday) afternoon.
-- Mike
From: Mike Jones
Sent: Monday, March 11, 2013 3:38 PM
To: oauth@ietf.org
Subject:
16 matches
Mail list logo
