Seems that ISO/IEC 24760 is yet another one that does not align with
Recommendation X.1252 (IdM terms)
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Igor
Faynberg
Sent: Wednesday, August 11, 2010 10:42 AM
To: Tschofenig, Hannes (NSN - FI/E
On Tue, Aug 10, 2010 at 11:00 AM, Oleg Gryb wrote:
> The thing is that each time when a web app with sensitive info can be run in
> a frame, security people would advice to break that
> frame-reads-other-frame-data logic, because it can lead to violation of same
> origin policy.
This is incorrect
Yes, there is Recommendation X.1252 (IdM terms) and then Y 2720 (NGN
identity management framework) has some terms in addition to that. All
documents in force are listed, and can be picked up free, at
http://www.itu.int/en/ITU-T/publications/Pages/recs.aspx.
Igor
Tschofenig, Hannes (NSN -
From what has been discussed in this thread (and other discussions before), I
see the need for the following variants:
- code in URI (Web App.)
- token in fragment (JS client app)
- code in fragment (installed app)
- code in URI + token in fragment (Web App. with JS Client?)
Any comments?
regar
Great comments; thanks to Christian for responding. To answer just a couple of
more points that I don't think got addressed yet:
Yes, we would very much like for dynamic client registration to become a work
item of this group. (Do we need to take any steps other than stating so in
this email?
I am not aware of the ITU-T terminology. Are the documents publically
available?
> -Original Message-
> From: ext Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com]
> Sent: Wednesday, August 11, 2010 7:31 PM
> To: Tschofenig, Hannes (NSN - FI/Espoo)
> Cc: OAuth WG
> Subject: Re: [O
Hannes,
This is indeed a very good idea!
ITU has been developing the IdM terminology for some time, so this
document should prompt the discussion and -- let us hope!-- the
alignment of normative terminology.
With thanks,
Igor
Tschofenig, Hannes (NSN - FI/Espoo) wrote:
Hi all,
Althought
Hi!
Am 11.08.10 16:36, schrieb Stefanie Dronia:
> Hallo Eve,
>
> I read your proposal, too. Thanks for providing it.
>
> Some questions:
> # first part of chapter 2
> # enchanced OAuth RS, AS and client are mentioned. Does the
> enhancement just denote, that they support dynamic client regis
Am 11.08.2010 um 17:40 schrieb Christian Scholz :
> Am 11.08.10 17:31, schrieb Torsten Lodderstedt:
>>
>>>
How is a UMA requestor envisioned to discover the auth server?
>>>
>>> On the Host side the user can tell it which AM (in UMA terms it's an
>>> Authorization Manager,
Am 11.08.2010 um 17:40 schrieb Christian Scholz :
> Am 11.08.10 17:31, schrieb Torsten Lodderstedt:
>>
>>>
How is a UMA requestor envisioned to discover the auth server?
>>>
>>> On the Host side the user can tell it which AM (in UMA terms it's an
>>> Authorization Manager,
Am 11.08.10 17:31, schrieb Torsten Lodderstedt:
>
>>>
>>>
>>
>>> How is a UMA requestor envisioned to discover the auth server?
>>
>> On the Host side the user can tell it which AM (in UMA terms it's an
>> Authorization Manager, some sort of extended AS) to use or it might be
>> discovered via web
>>
>>
>
>> How is a UMA requestor envisioned to discover the auth server?
>
> On the Host side the user can tell it which AM (in UMA terms it's an
> Authorization Manager, some sort of extended AS) to use or it might be
> discovered via webfinger or similar means.
>
> The process for requeste
Hi!
Am 11.08.10 12:40, schrieb Torsten Lodderstedt:
> Eve,
>
> thank you for writting this document. I consider it a good starting
> point for a discussion about client registration and discovery. Will
> you propose this as a WG item?
I think that's the plan as it is more related more to OAuth i
Hi!
Thanks for the feedback! :-)
Am 11.08.10 10:20, schrieb Lukas Rosenstock:
> Nice to see this draft!
> I've just read it and would like to provide some feedback:
>
> 1) redirect_url vs. redirect_uri: In different flows, different terms
> have been used. I think that should be consistent and i
Hallo Eve,
I read your proposal, too. Thanks for providing it.
Some questions:
# first part of chapter 2
# enchanced OAuth RS, AS and client are mentioned. Does the
enhancement just denote, that they support dynamic client registration
or have any further requirements to be fulfilled by th
Can you explain your use case a little more, and provide an example of why the
current system doesn't work for you?
We have had numerous previous discussions about the format of scope, and the
spec represents the consensus around how people plan to use them.
http://www.ietf.org/mail-archive/web/
Hey,
We have a use case for a scope that's more fine-grained/flexible than
what you could explain in a set of space-delimited keywords. We would
like to encode things like the precision with which some data can be
accessed, and the scope sounds like the reasonable place to do that.
Of course we
Am 11.08.2010 um 12:40 schrieb Torsten Lodderstedt :
> Eve,
>
> thank you for writting this document. I consider it a good starting point for
> a discussion about client registration and discovery. Will you propose this
> as a WG item?
>
> My comments & questions:
>
> You propose a host-m
Hi all,
Althought this request is only indirectly related to the OAuth protocol
work I nevertheless think your input is valuable. We have just submitted
a new version of the privacy and identity management terminology
document:
http://www.ietf.org/internet-drafts/draft-hansen-privacy-terminology-
Eve,
thank you for writting this document. I consider it a good starting point for a
discussion about client registration and discovery. Will you propose this as a
WG item?
My comments & questions:
You propose a host-meta based discovery of the registration endpoint on the
authz server. Could
Nice to see this draft!
I've just read it and would like to provide some feedback:
1) redirect_url vs. redirect_uri: In different flows, different terms have
been used. I think that should be consistent and it should be uri.
2) Data formats for requests: This spec uses JSON for everything. The co
21 matches
Mail list logo
